Plus… if we can entice some other devs in to the game with bigger and more exciting ideas, so much the better!
There you go!
I think a lot will still be covered by the CLI. As long as devs are working in relative folders etc, then version navigating should be relatively easy (ahem). Basically static sites/blogs etc should be dealt with quite well across the board.
Adding in more complex JS / dynamic sites… Well, we can pin down the JS version loaded into a page, and what we enable that do is, well, I guess to be decided. We can limit/block resources that are not specifically versioned, eg.
I’m not sure of that. There’s already quite the movement towards static / precompiled pages etc. A lot of CMSs effectively output that via caching for example. Things don’t have to be dynamic all of the time.
But it may be that there are a lot of modern frameworks there too. (We’ve been using react for patter etc eg). But again, I don’t necessarily see that as being problematic…
Though yeh, it is all very abstract atm. I’m excited to further with the CLI so we can really start playing around with this and see what we can do!.
There’s also another idea (not much thought out beyond what I’m putting out here) that we could enable folk to ‘fingerprint’ a page / version, and so lock it down in that fashion ie: these are ALL the resources the page loaded when I ‘saved’ it, and share that. And all of those resources would still exist no matter how many versions a site has gone through.
Such a thing might even be able to handle re:serving dynamic content (ie from a fingerprint, serve the js comments from
safe://happybeing?v5 even though the JS is asking for latest version).
As I said, that’s not a very well explored idea, but I think that should be possible and it could be another alternate way of using the PWeb.
Can you explain how this works - is it because the links to versions are maintained in RDF in some way rather than via URL with version parameter?
If it’s the case that uploading a folder structure and using relative paths can easily be versioned, I think all cases are covered, but I don’t understand this yet.
I want to start poking under the hood of SAFE CLI soon, so this is very interesting!
The issue here isn’t static v other, because both have a build process. However, that should be ok (or able to be made to work) by what you’ve said above if I understand. Because the output is a folder heirarchy with HTML, CSS and JS files a client side framework, a statically generated site or editing manually. All of which can be treated the same way. It will be a matter of handling or translating URLs to ensure everything within the folder tree is accessed relatively. That could even be done in the browser webFetch().
Sounds cool Thanks for explaining.
If your site is a folder of assets eg:
/index.html /css/style.css /js/min.js /blogs/post1.html /blogs/post2.html
The assets for style.css etc are relative to the base url. Which in this case ends up being the
FilesContainer (aka folder) where all these are saved on the network. So a change to any one file is actually a change to the
FilesContainer too. So you should be able to happily check out entirely how the site was at version 5. CSS/JS/blog posts and all.
This should work whether you access the
FilesContainer via its own xorurl (
safe://sdaifsdfdiofjoidfjsofhwe8f9fhdsfodjsfjf?v5), or via any domain/publicname/etc which points to it.
Ok that’s very neat and I want to play with it so stop letting me waste your time! Seriously Josh and everyone, this is really great stuff! Thanks all.
So your on safe:// editing a page, how is ‘page history’ time based?
We know Joe Bloggs was at the internet cafe on July 4th 10:00am and since you have surrendered your keys to us, we can now see you were editing the website in question at this exact same time.
So we can therefore say with confidence, you were the one who produced the hate crime against the state.
@JimCollinson your designing will be seen as on par with the likes of Jony Ive someday seriously beautiful stuff. Keep it up!
I seriously doubt that. But thanks though!
I’m just in the right place at the right time, and get to work on this amazing thing.
I know there is an opening at Apple now though… but I’ll have to politely decline. Bigger fish to fry!
I think recognising this is one of the things people in this community and who are part of Maidsafe have in common. I also think it’s a skill, or an aptitude. I think it gets labeled unhelpfully IMO, as ‘passion’ as in ‘what’s your passion?’ etc. I think it’s unhelpful to put it that way because it makes this into a thing, when it’s ‘a way’. You get to feel you’re in the right place at the right time when you are on your way in my experience.
We seem to attract people who are on their way, while each is also different, often markedly so. Maybe sensing the importance of our way is why we also clash heads sometimes!
I value, admire and am inspired by you @Dimitar but I would not try to do the things you describe there. It isn’t my way, so it would be hard, I’d be unhappy trying, even though I can see how beautiful it would feel if I could do those same things. I enjoy the joy you obviously feel though. It’s beautiful, and I’m very glad you shared.
What I’ve learned is that my way has an ease to it, an excitement, and once I realised that following those things worked for me I stopped fighting it and trying to do what I judged were better things. I’d call it self indulgent, but it isn’t, it’s just my way.
I’m guessing Johnny Ive has this, David clearly has, and many here - but each their own particular way. And maybe that’s also what underlies the need to move on for some. The need to follow those individual clues that something in us just knows is our next step. Our next step.
Cultivating your way is a good thing IMO. I couldn’t help it: I was lucky that I had the freedom and opportunities that allowed it to grow and become compulsive.
It can also be a collective thing, and right now the community and Maidsafe are on their way. Can you feel it?!
Preach Brother! Respect!
We’ve not got to this feature set yet, we’ll be working on all that kind of thing in future sprints, or even milestones.
At the moment, to contain the feature-set, we’ll be working on the basis of there being a single draft site (but with multiple edits/versions). Again, this is to keep the design and implimentation work somewhat contained, and building up from there.
It’s pretty easy to envision how we could accommodate mulitple drafts in future iterations though, so it’s on the radar.
So the only thing that can be understood to be a hard truth will be the sequence of edits, as there is no notion of time at a network level.
So timestamps will come from client supplied metadata, and are intended to be guide, and a way for end users to have some indication of a timeline, but they cannot be relied upon absolutely… as technically they are optional (and we have helpers/tooltips to point this out to the reader).
If you have surrendered your keys, then you have much bigger problems, and you’ll be unmasked as the editor regardless of the time stamp I’d imagine.
No metadata and no edit records…as default. Opt in if you want those features.
When you say edit records, what do you mean exactly?
Are you referring to the identity of the publisher? By default this (as well as the site ownership) will be anonymous.
Exciting stuff! Thanks for the update. Re: the grace period before the publish becomes permanent will there be a feature to adjust how long that period may be. Looked like it happenned pretty quickly on the vid. Thanks!
Maybe… it all depends on how bloated we want this thing to become.
Yeah, it was just an arbitrary time used as an illustration for the presentation. It’ll probably be around 4-6 seconds in reality, as it’s stalling the publishing. We’ll probably add in a dismiss button which would then publish immediately, and navigating away would also publish immediately.
SAFE By Default
From what I can see it’s page history.
Look at it this way, when you give the world total privacy with no possibility of backdooring, governments are going to pass laws that permit their representatives to demand the surrender of keys.
The whole world now knows that nothing is truly secure, everything can be backdoored.
So when a technology comes along that promises SAFE, then it better deliver by default, otherwise there should be a disclaimer on every front end software you release, advising this is the case only when all the right checkboxes have been ticked.
We have to always think from the perspective of the most vulnerable humans in the most dangerous of circumstances. This network will provide real hope for those who are too scared to speak out about their situation, it better well do what it says by default…every single front end software, by default, no crumbs, no records, no logs, no page history etc etc etc …by default.
31 posts were split to a new topic: Safe authentication considerations
It looks amazing! But I have a question, why was it decided to have the “add file” button on the address bar?
I would feel that it would be more intuitive to have it near the file tree (for example, a plus sign next to “site files”)
And the detail of having a delay to “undo” a publishing is very thoughtful