I’ve been keeping it hush hush for about a month now as I learn what I needed to learn and experiment, but if I can get enough time in and figure out a few trouble spots before schedule ramps up I’m going to try and have what we both want ready soon… don’t want to make promises and not deliver though… FUSE is a little tricky, so that will be phase 2.
This update is a little bit earlier than expected, just another little teaser since @AndyAlban uploaded a fancy video in his Safe-Search post and I got video envy. The simplicity of creating public names with the Safe-CMS app:
In the video above, I’m creating a domain (public name)
safe://hellosafeforum, showing what happens when you try to create it again (and it already exists) and then showing that visiting that new public name in the safe browser (it elicits a 106 error - because we didn’t create a service under it). After that, I attempt to load a public name which doesn’t exist (which elicits a 103 error, because the public name doesn’t exist), before finally returning to the
You may also notice a full authentication cycle with the Safe-Authenticator.
I’ll post another teaser showing service creation in the run-up to my major update post this weekend showcasing the creation of draft posts, publishing of posts, previewing them locally, etc.
Based on where I’m up to at the moment, I believe I will have the first official “template” for blog pages done some time in the next 10 days and I’m well ahead of my expected release schedule (so we may possibly be releasing a week earlier than I expected).
Hi guys, this update is tiny, but it’s one that I’m really excited about!
Above is some flat HTML content I’ve uploaded to a public name / service combination, all done entirely within the application! What this means is that we have full integration with the SafeNet libraries and everything from this point forward is purely an exercise in user interface creation. (the service is
shane4 because I’ve spent the night bugfixing and increasing performance and reliability, so some testing was needed.)
As minor as it might seem to simply see a few words of text on a page, it marks an absolutely huge milestone for the project and guarantees that I’ll be able to deliver with the expected features before the expected delivery date of the project.
you really are doing a marvellous job here i can’t wait to test the CMS =)
aaannd we have lift off !!
Hello all, first of all I just want to say a massive thank you to all of you for your continued support, publicity, etc. It’s really appreciated and makes working on this much easier for me. I’ve been working on this project for 3 weeks now and your support during that time has been amazing.
The video below showcases the creation of a public name, a service within it, then the creation (and upload) of a simple, template-less bog post at the address
index.html, you can verify this all yourself by visiting safe://www.hellosafeforum2/ in your SAFE browser.
This is all obviously a little bit rough, there are no indicators for when things are loading / saving and the “timeline” on the post edit page doesn’t update to “published”, but it’s very nearly there. From here, the only things I have left are as follows:
- Add some nice loading indicators as said above
- Create the template compiler
- Create a few “default” templates for our lazier users to take advantage of
Finally, I’m confident in the work done so far - enough to finally set an official release date: February 24th 2018.
Really great work! I think this helps to demonstrate how decoupled the client can be from the resulting content. It feels much more like how people treat apps on mobile phones and tablets, rather than how desktops tend to revolve around the browser more for this sort of thing.
IMO, this is actually quite an interesting differentiator. It could mean people expecting a richer client experience, more akin to what mobile users expect. I suspect it may mean people will explore different client side tech stacks too. Anyway, it is just interesting to see this process evolve.
This is amazing work, Shane. Congrats on the blazing progress. The SafeNetwork community is lucky to have you, and your work will be extremely helpful to many projects.
Thanks. Good shane your post.
Yeah, you’re right about that.
I thought it was important to abstract away the complexities of the SafeNet - at its core it’s difficult for a lay-person to understand, but if we (app developers) can make it work in as few inputs as possible from the user’s perspective, it won’t seem quite so daunting. Breeding familiarity was really my goal with the user experience.
I hope it’ll serve as a decent, simple entry point for new users to try out publishing on the safe net before they move on to tools with more depth.
Again, wow just wow! The rate of progress is amazing!
To this end I think it essential to provide additional explanatory pop ups for those that might be confused by the service field and it’s orientation on the left of the URL as opposed to the right. From my understanding subdomains traditionally fall the right. The “post domain” field imo could either use further explanation or rewording to something like “Post this to which domain?”. Finally The “post URL” field might be the most confusing of all for new users. Where the need to specify an HTML and the index at that isn’t obvious.
With your goal in mind I’m sure making this grandma easy will naturally happen
I’m not sure of the reasons, but MaidSafe use the terms profile and public-name, as in
safe://profile.public-name and you can support different services (www, LDP, etc) on each public-name by associating each service with a profile.
In the absence of any other convention, I’m using the term host in my SAFE Web API
to refer to the whole
All really valid points - like I said above, it’s all a bit rough at the moment, the focus until now has been network features, but now I have a few weeks to really nail the user interface.
With regards to domains, however, traditionally the domain structure of a website is as follow:
PROTOCOL://SUBDOMAIN.DOMAIN.GTLD/PATH, for example:
https://www.google.com/search - as you can see, subdomain is oriented to the left of the domain.
No I mean exactly as I described, so it’s the Maidsafe term for subdomain.
However, as I say, I don’t know if that is significant - but as it’s used in their RFCs, I’ve followed their convention in my API.
Is there a reason we can’t have PROTOCOL://DOMAIN.SUBDOMAIN/PATH on Safenet? It would just feel more intuitive to me. Is the GTLD even needed? E.g. safe://google.search/scholar, safe://google.search/images, safe://google.company/contact.
Yes, but I think it’s fair to argue that the traditional route is NOT the best. Given an un-official set of standards, the safe dns can be self-organizing through typical conventions. For example, if I want to add my take on a search system, no one can stop me from simply using “safe://search.with-jlpell”, but people will soon find out that “safe://search.with-google” works better, and “safe://search.by-shane” works way better still. If you are a cat photographer, just post your best CC-SA 4.0 to “safe://cats.by-shane”.
After I thought about the analogous “subdomain.domain.gtld” structure on SAFE from a user interface perspective a little bit, I like it way better than the current web. Seems more intuitive and natural. There are a lot of ways for it to self organize around a simple “style-guide” without forcing people to do anything.
I also think that instead of the WWW codes, we should change the moniker to something else like SSS or SOS and come up with something more creative than “Secure SAFE Site” or “Sites On SAFE”. (Unless a consensus of people think those are decent enough alternatives.)
The only things stuck in a web are victims and vampires.
Hello! If anyone is interested in beta-testing the app, I could really use the following:
Someone using Windows (7 or 8.1 preferred - I do support 10 fully, it’s just what I use for development so it has already been tested to death), someone using OSX (10.9 to 10.12 - again, 10.13 is supported but has been tested to death) and Linux (“Ubuntu 12.04 or above”, “Fedora 21 or above” or “Debian 8 or above”). At the moment, ARM support is spotty at best.
I won’t be needing you for another week and a half (or so), but I just wanted to build up a small list. I’m not looking for a lot of beta-testers, just one per platform if possible - if you post here and aren’t chosen, it’s not for any particular reason.
Those testing will be required to have at least 100 puts available on their SafeNet account (as such you’ll need to have the Safe-Browser installed and a valid Safe-Authenticator account) and will be uploading content to the Alpha2 (the current live) network. You must have a keen interest in posting to the network and writing some content privately before the test would give you a great advantage.
In return, you’ll gain first access to the CMS platform (though I do recommend you upgrade to the 1.0.0 stable version at the end of the month), but you will encounter bugs, usability issues, etc. All testers will be credited in the
contributors.md file in the Github repository once it’s released.
Edit: I’ll post testers below on this post:
Hi Shane - I’m in! Can do Debian 9 and Fedora 26, Win 7 too if needed. We can give testers new invite codes if they are short of PUTs. Cheers
Perfect - I’ll just sign you up for Debian / Fedora if that’s okay? I want the test group to be small but it’s also important to have some variety (both of environments and technical capabilities of the users)
I’m running Windows 7.