Perpetual Web Browser UX — Editing and Publishing Sites

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.

1 Like

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.

1 Like

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.

1 Like

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


I see what you are saying now, you want the ability to publish data, with no link back to the original account, not even within the account itself.

Yes, that should be possible, but whether it would be desirable as a default is another question… it would mean, for example, only ever being able to publish to a public name / site once, and then never again.

This could be done with just publishing to a XOR address, a kind of ‘data drop’ mode, completely hands off, and that is something that we’ve discussed in the past… it’s just not for this set of personas.


I’d vote for a data drop mode, I’d consider it an essential feature… however you choose to implement.

I have just been watching the video, I really like the idea of having an editor within the browser !
Little detail maybe but I have to agree with @piluso about the placement of the “add” button, it feels a bit weird that it is in the url bar. Maybe it would indeed more intuitive to have it in the left “files” panel.

1 Like

Yeah, we’re still working through some of the finer details of the interactions around adding pages/files/directories.

Initially it started life as a way for the user to interact solely through the address bar… “I’d like the create a new page with this URL please”, and it makes sense in that context. But adding ‘folders’ and files, may feel more natural in the left pane, where the overall structure is laid out. We we’re planning to have designs on both.

Which would be more intuitive for the user? Do they think about a site structure more as an address string, or a hierarchy of folders? Does having both lead to confusion? Does the URL bar become less useful or polluted with an edit control within? We’ll only get the answers this by testing, and test we will!


To me, a hierarchy of folders is more intuitive.
Yes, having both could be confusing.


I think it depends on whether we maintain the old workflow/UX or if we can provide a simpler UX that works for one simple job. I think it’s too early to decide, so would like to see the new ideas taken forward to find out, without trying at this stage to keep within existing UX expectations (eg folders).

Folders are used for good reason, but maybe for this we don’t need them.

For example, we don’t manage the elements inside a Word document using folders. The document itself provides the UI to manage and manipulate the images and other objects it contains.

At the moment, Tony 's use case looks more like document editing rather than document management, so I’m not sure he needs folders for the document content. They may come in for a more complex use cases, and for document management.


@JimCollinson I imagine you are already, but if not, please follow what Paul Frazee and his team are doing in this same area. It might also be worth pooling ideas.

Also, Aral Balkan is excellent on good UX (and dark patterns), so might be worth reaching out to him at some point.

Yeah, I’m familiar with their great work, and we studied it a bit before embarking on this work.

It’s a tricky balance, and why I mention testing. You can often start out with the basic building block of something quite simple and elegant for a very basic, or narrow usecase, but it can be deferring complexity to a usecase further down the line, so and it can get worse from there.

The starting point we had with this was really just simple pages, built from the address bar, in the same way that a user might think about urls. And it can feel quite natural; type an address you’d like content to live, then just drag in a file, or start typing and there you go!

But then things start to feel a little more disorienting once you want to make adjacent directories in the tree structure, or deal with large containers of images say, or linked things like CSS. It becomes harder to comprehend, navigate, and find things you need, if you can’t see the site structure in some visually mapped form; especially while there is no front-end to navigate around.

So, then you get to questions of representing that structure, getting around it, seeing which files have been changed within it… and then also how it’ll work with a structure of private files you already have uploaded to the network, and other related tools that are used to navigate them.

So, sometimes you end up gravitating back to a tried and true, in order to spread the load of complexity a bit, which might be to the detriment of a really simple usecase. As much as it is my desire to push the boat out some times, and forge a new path (often a desire probably tinged with ego if I’m honest).

It’s gonna be really interesting to watch people using all this though… and have our assumptions proved laughable!

Also, on top of this, there it’s worth remembering that there will be a lot of brand new paradigms for users get their head round, with a significant cognitive load that’ll come along with it e.g. perpetual data, and version histories of sites etc. So sticking to a tried and true, even if it’s a bit clunky, might be the right decision… not only for the user, but also for the team to focus more on the more radical parts of the picture.


Even if it is only useful for something simple - like a public homepage - being able to just type that, drop an image, make it a background, click to add text, edit some metadata (default font etc) I think this could be worth doing.

It can bring simple web publishing to everyone, and that’s a lot of new users - and undermines the power of Facebook et al who exploit the difficulty to get people to do this kind of stuff on their platforms.

Then you can build in that.


Yeah, that’s certainly the aim. And we’ll try and look a bit more at the really simple site build flows once we get on to the new site creation workflow etc.

I’d been wondering if we could do a markdown mode, and then just layer on a basic stylesheet/template choice etc, and how this could perhaps interface with a notes type app. (We haven’t forgotten those parts of Tony’s persona BTW, just biting of sensible chunks).

I think we could do something really elegant and fast to use there, and especially when it could be pre-baked with linked data, and then hooking in to a SafeID profile for a feed of posts etc…

Super simple and fun for the user, normally means a boat more work in design stage though… so I can’t promise this all from the get-go. Exciting nonetheless!


Expectation management - check
Delivery - …!