The _publicNames container, like any of the other default containers available, is a private MD’s and their entries are meant to be encrypted. The purpose of these containers is to work as an index of what an user/account owns on the network, e.g. by keeping track of xornames of MD’s or ID’s created at random addresses on the network.
When you create a website, the public id is stored in the _publicNames as the key of an entry which value is the services container address, as an encrypted entry. But the services container is the one that actually has the list of services mapping to websites, or email inbox, etc., and it’s stored as a public MD with the address calculated with sha3(<public id>).
When you are fetching a website by its public id, let’s say safe://my-service.my-pub-id, the browser (actually the webFetch function in safe_app_nodejs) looks for the services container located at sha3('my-pub-id') and it looks up for entry with key ‘my-service’ to be able to then fetch the website’s NFS container where the website’s files are stored. As you can see the _publicNames container is not used at all, and as you realise it couldn’t be used as it’s encrypted.
That’s interesting, in that case I’m miles off and the issue lies elsewhere. Fun!
You know, this is really the thing I like most about SAFE network development, it’s so far removed from what I normally develop that I’m constantly making mistakes and learning, whenever people ask me how I got to where I am, the answer is always “I’ve made a tonne of mistakes and learned how to not make them anymore”. Anyone else out there who is bored of development as a career and looking for a change, SAFE Network development is a lot of fun, with some great challenges and a lot of moving pieces to consider.
Thanks @bochaco, I apologise for pinging you over this, although your explanation is good to have in one place. I wasn’t thinking straight when I looked at the code last night - woke in the middle of the night realising of course, the _publicNames container has to be encrypted (or anyone could tie different names to an account) and that serving websites only needs the public name services container (MD) to be public. Doh!
Thanks to Shane too, because I hadn’t realised I needed to encrypt those entries and will fix this in my code. Another bug squashed!
I second what Shane said here about developing for SAFE being fun. It isn’t easy, even though Shane has made it look easy with his incredible speed and professionalism, but he’s a very experienced and skilful developer. But overcoming challenges is what is fun about development for me. The key is to enjoy the little challenges, also stick at it, ask for help, and take a step back sometimes… gradually you start to make little wins, then bigger wins and one day you can be as smart as Shane, well smarter than me anyway
That’s awesome! Have you tried publishing a template? If you go to the templates tab, click on “Whisper” and select your domain, then click “Publish to SafeNet” it’ll automatically style ALL the pages on that domain for you.
And that’s not your stupidity, that’s my validation error, thanks for mentioning it.
Please be aware that version 0.0.5 is now publicly available, it can be found here: Release 0.0.5 · badcodeltd/safecms · GitHub - I still don’t yet have a MacOS build up-and-running, but this is expected within the next 7 days.
This release fixes the following known issues (as well as improving stability and performance):
If you have any questions or issues, post them here or on github and I’ll address them, if there are any major breaking issues, I’ll publish a 0.0.6 hotfix. The next expected release is a stable 1.0.0 release, fixing the remaining issues and publishing a MacOS build.
Thanks,
Shane
Edit
Links and text updated, 0.0.5 is now the valid release candidate due to a hot fix.
I’m trying to run safe-cms-0.0.4-linux. I unzipped the package and made the file safe-cms executable. I ran the file from the terminal on Linux Mint Mate 64-bit, but there is just a window stuck on “Opening the SAFE authenticator” for at least several minutes. No info in the terminal. Am I doing something wrong? Should I have Peruse running at the same time?
Hmhmm since the authenticator is bundled with the browser and safe CMS probably needs account access I would try it with the safe browser running at the same time
I have peruse-v0.4.1-linux-x64 running now, but trying to run safe-cms-0.0.4-linux only results in a new window “Opening the SAFE authenticator”. Should I try with safe-browser-v0.9.0-linux-x64 running instead? I’m downloading it now. My connection is bad for some reason. Maybe that’s even my problem with the Safe CMS. If needed, I guess it would make sense to have SAFE-cms start the browser automatically.
Safe-CMS starts the safe browser by default using the URI exported by the safe browser (safe://) and, i believe, (safe-auth://). If it’s failing to start, it could be because of a Javascript error (if so, please give me the output of the console in “Right click → Inspect Element → Console”), or because of an issue with Peruse. At the moment, I’ve only extensively tested against the Beaker browser, but I’ll expand my testing to include Peruse in that same scope.
It may also be worth running the safe-cms executable from a GUI (your file explorer) instead of the command line, there could be some weird stuff going on like the safe-cms being a child executable of the shell window, etc.
I’ve the same problem on my Linux Mint.
Here the requested Javascript error: safe://logging.draw2/safe-cms-console.log (resources/app/node_modules/@maidsafe/safe-node-app/src/native/libsafe_app.so missing?).
I totally understand the issue now, thanks for that dump. I package all of my releases from the same machine, when i package for Linux, I (apparently) need to trigger node-gyp to rebuild the safe_node_app OS specific files - I had assumed this would be done by default, now I know about it I can add it to the build pipeline. I’ll have a working version for you within 30 minutes, thanks.
Ps: i had to give file safe-cms execute rights (chmod a+x …)
I’m still getting used to it.
The Posts I could access with Peruse: safe://cms1.doc2/tpost.html.
But where can I see the Whisper template (also published to safe://cms1.doc2)? Or am I doing it wrong?
The template itself is located at /template.js on any domain the template is published to, in your case safe://cms1.doc2/template.js. At the moment, it doesn’t automatically update an index.html and you have to manage this yourself, but support for this is planned within the next week or so.
With regards to permissions, this is because at the moment I’m just distributing a big zip directory (and this is referenced in the README.md under installation with Linux: safecms/README.md at master · badcodeltd/safecms · GitHub), once I move to a signed AppImage with release version 1.0.0, this won’t be a problem anymore.
Good morning! SAFE CMS seems to be working for me now. The first time I executed safe-cms of version 0.0.5 a Safe Browser window opened (Not sure what version. It doesn’t say.) and I was able to authenticate the program. But then the SAFE CMS window just remained blank. I couldn’t close it by clicking x in the upper right corner but had for force quit it. The next time I ran SAFE CMS it seemed to work as expected. I’ll be testing more today. Thanks again for your hard work, @Shane!
