Perpetual Web Browser UX — Editing and Publishing Sites

In this design sprint for the Perpetual Web Browser, we’ve turned our focus from Laurel’s ‘Read-Only’ Persona, to Tony, and his needs as a content contributor.

How can we make it fast and straightforward for Tony to create, edit, and publish a site on the SAFE Network, taking advantage of the serverless infrastructure, and the versioned perpetual data?

Let me walk you through the candidate designs, with a YouTube screencast of the latest work:


These are the kind of post that make my day, all the backend code-y stuff is important, but so hard to wrap your head around, the UX posts on the other hand make the network seem so more alive then any amount of text ever could!

Keep them coming!


  • The image you add to to site is stored as a private file, would the browser download the file then reupload it as a public file? I’m mainly asking for cost but an extra warning may be usefull as well since it was stored privately in the first place, then again, it also has a xor-url.

  • I’m a cheapskate, could you show aprox put cost somewhere? or is that not accessible?

  • Is there a way to explore the edits you make on the site/page itself before actually publishing the changes?


Looks very cool! An in-browser editor seems very useful!

Just a few questions to clear some stuff up. And of course I’m immediately thinking about the technical stuff… :wink:

  • What is the difference between the My Sites and Bookmarks? Is it just about what purpose they serve? (If so, then why not a folder ‘My Sites’ in Bookmarks?)
  • Does the browser detect ownership of the SAFE name, so it can show the edit icon? Or is the icon available always, so people can traverse the SAFE name directory without editing it? Or is the icon based on the ‘My Sites’ list?

I also think very cool :smile: and am also going off into other thoughts…

a) how would this work with current popular workflows which include frameworks, module import, bundling/preprocessing and (in the case of sveltejs) compilation? I’m not looking for an answer here, I’m just wondering out loud because I don’t think there is much mileage in editing static HTML (even static sites are usually generated these days). I’m not sure there’s an answer anyway, so I’m also wondering…

b) Might this be a foundation for new workflows which, for example, do the work of frameworks and module imports within the browser environment? Or perhaps ways to build websites by choosing an existing website/template and providing customisation through a configuration layer using an interface in the browser? I guess this is a CMS app in the browser that ideally doesn’t touch the local file system, although I think that’s a big ask atm!

Also, like @isntism I’m wondering how we manage wallet balance, PUT costs and PUT minimisation in an editor environment. And how we can do this not just for browser built-ins, but third party apps. Tough questions I know, come on Jim and team! :stuck_out_tongue_winking_eye:


I assumed the in-browser editor was mainly for simple tasks and publishing. The whole web development workflow shouldn’t be an aim for the SAFE browser to incorporate. That’s what we have command line tools and IDEs for.

I’ve had a bit of a concern since I’ve seen the ‘history pane’ — the button that shows the versions of the site. I was thinking about version compatibility and the in-browser editor might easily produce a problem: If you use a new stylesheet that you upload and use in the HTML, what will happen to the previous versions that references the old stylesheet? If you remove the old stylesheet from the SAFE name appendable data (I assume that’s the data type used?) then the stylesheet will basically become a 404? Is there anything in the UI that warns of this?

I ask this because in the screencast I see URLs like /style.css. What if that file is changed? Then previous versions of the HTML page will also change. My question is basically how previous versions are assured to stay the way they were when they were published.

This question can get very technical. Perhaps all URLs will include the version, then my concern is irrelevant. And the above is just about static sites, it’s even more complex when including dynamic data loaded through JavaScript.


I’m fairly sure the old versions would also have the old stylesheet.

I think of it like any edit simply makes an entirely new collection of files and tells “blog.tony” that that is the most recent version, so if it worked once that perticular version will work forever.

Could be wrong though.


I’m quite sure that’s the way it is supposed to be, yes. Otherwise the history pane wouldn’t make sense and you would only broken pages.

But, from the screencast/mock, I’m not seeing how /style.css could work if it is a versionless URL. Anyway, perhaps I’m picking up on some HTML that’s not supposed to be read in detail. :wink: Like I said, perhaps every URL will have the version in it, but that would raise another question: How would Tony know what the versioned URL is of the stylesheet?


Tony’s persona seems to be a clear statement that this is the beginnings of a basis for site development, and trying to see how that can be useful is the reason for my thinking out loud above. Maybe I’m not understanding what you mean by ‘simple tasks and publishing’.

These days web publishing is mostly either 1) on third party walled gardens (like facebook) which is obviously not Tony’s use case, or 2) using a CMS (like Wordpress), which is my point b), or 3) self hosting something built using CLI/IDE/frameworks/modules and a build process, which I’m puzzling about with my point a).

Tony’s use case seems to be 2) or 3), so I’m assuming that the mock up is a step towards something with that kind of capability, but with a very different implementation.


You make a good point, @happybeing. I just looked back on some posts about the personas.

@JimCollinson made three personas, a reader, contributor and developer. Tony is the contributor and “publishes via simple CMS systems, usually via the browser.” And “knows basic HTML and CSS.” I’m now a bit confused as the mock up does indeed make me think this is more about development than contributing, as a contributor would hardly ever edit pure HTML/CSS.

By this I mean all the file management and uploading that comes with the publishing. Looking at the file sources, managing the sites and maybe editing site’s config files. Everything but the real development, which I wouldn’t do inside such a browser. Or at least I think MaidSafe shouldn’t focus on creating a full-blown developer experience within the browser. From this perspective the in-browser editor surprised me a lot, I didn’t expect this, but it seems very nice for hobbyists and developers. (Developers would only need the CLI and/or hosting manager.)

Anyhow, I hope @JimCollinson can shed some more light on the background of things.


He’s trolling us :wink:

1 Like

I was under the impression that the / in /style.css meant “the folder this file is in”, and yes the network itself doesn’t store folders (neither does your hard drive), but it can store files that act as folders which the browser could interpret as such.

In which case you can just copy it and the files it references and have the exact same, yet entirely indepentent site, then make your changes there. (or just edit edited references for efficiency)

But yeah, you may get a 404 if the website loads another website(newest version) that got changed, so use versioned sites unless you don’t expect to find any specific file.

(some more, not neccessarily UX questions)

. Can other people who have edit rights see (and edit) your autosaved drafts?
. How many drafts are stored?
1 Like

Put cost minimization by requesting fullness of network areas and choosing appendable addresses that start with the right prefix :face_with_monocle:

We’ve been discussing about this a few days back, and one of the ideas we are considering was that the browser (and potentially the resolver in the APIs) will resolve NRS/DNS URLs only as the first/top-level fetch of a site, but all links contained within the content fetched from that URL will need to be versioned XOR-URLs. If an HTML published at safe://mynicename/index.html contains some non-versioned XOR-URLs links, those will not be fetched and rendered. Note this cannot be enforced as users can upload sites using other tools not following this convention, but it would become the convention/standard for the pWeb browser.


We havent started any coding or even implementation plan of this yet. That said, probably the icon would be base on a sites list maintained for the user. Ownership checks probably being a bit more complex, but something desirable in the long run.

As for the button always existing. I think some variation could be cool to have some icon for forking things.


It prrobably wouldn’t. Or would be of limited use. I think those ‘advanced’ sites will likely find more use in safe files sync ./www safe://<file container>.

I’d wager at some point this set up would be expanded to offer markdown editing to keep things simpler.

b) Something like that doesn’t sound impossible. You could easily hide away compilation of a react-static or svelte theme in an extension. So you edit, it compiles, and then allows an upload. Totes possible.


re: style.css. as @bochaco notes, we have some ideas around this. Our tools could parse/automatically insert versions to things.

Or, if style.css is relative to the HTML, (ie, in the same FileContainer as the index.html, then any change to one or the other updates our FileContainer version. So they’re always paired at a given version. This should make for browsing around old sites using a relative folder struct pretty simple.

That said, things have the potential to get very complicated w/ pulling resources from NRS etc. Hence our thinking around a requirement for versions in links for the PWeb.

All very fun to try and think around both what’s possible, and what we can feasibly do here!


This isn’t 100% agreed/design yet I don’t think, perhaps dig into the DataTypes RFCs and associated discussion if you want more detail though. But I’m designing the UX around the understanding that it wouldn’t be a re-upload, just a change in type. There’d still be a minuscule cost associated with a change the the site’s map though, but insignificant I’d think.

We’ll get to the interfaces and UX of costs and cost management in future milestones. So let’s talk then :grinning: But suffice to say that the costs of making edits like those shown in the video are gonna be so small as to not worth the hassle of pre-warning etc. So perhaps it’ll be a case of just agreeing spending limits on an app, or a threshold that produces a flag—likely from a transient external app, or module. But again, future milestone will see us work on that.

Yes, you can explore the unpublished change history in the Version History pane from edit mode.


My Sites are the sites you own or have access to edit, Bookmarks are any site that you wish to, well, bookmark.

  • Does the browser detect ownership of the SAFE name, so it can show the edit icon? Or is the icon available always, so people can traverse the SAFE name directory without editing it? Or is the icon based on the ‘My Sites’ list?

The edit icon will only appear on sites and resources that you own, or have permissions to edit. My Sites is just a convenient way of showing all the Public Names / Sites / “Domains” that you own


We have a specific persona to deal with that Yanni who’s needs revilve more around these kinds of use cases.

What we are tackling with this one, is the most basic editing possible really, basically—a simple text file. It enables us to start small and build up from there, as there are many associated facets to the experience that we start to tease out once we start adding data.

Undoubtedly things will get more advanced. But jumping straight into a CMS app in browser is a boat load of work. So we’re starting small (circa '94 :joy:) and moving on from there.

I do think there is a beauty in being able to create a simple site, simply and deliberately., and it’s especially immediate and exciting when no infrastructure has to be thought about. Much of the cruft of modern CMS is there in order to shelter users from the administration and pain of server based architecture. I’ve often dreamed of the ability to be able to get right in and edit a page from a web inspector—no middle men.

Sure there are plenty of advanced features in modern frameworks that are desirable and useful. But again, we’re trying to get the basics useful and immediate for Tony, someone who knows I tiny abmount of HTML, and a smidge of CSS.


This does seem to be a problem with the idea of the pWeb - as I understand it, to get versioned websites you will have to use special tooling that grabs the versions of all referenced files when the site is uploaded, and inserts the version into the referencing URL.

This may work if you are editing in SAFE browser (as illustrated), but for anyone uploading separately it will get very tricky, and this is how most websites and apps will be built.

So if I understand correctly, the pWeb is a) optional and b) tricky to support rather than universal. :-/


Yeah, This is just the beginning really. You’ll notice that in the add dropdown there is a placeholder for template and I’ve toyed with the idea of this rolling out a set of markdown enabled templates, and basic site structures ala Squarespace orwhathaveyou, or maybe even community resource bare bones site templates.

It’s certainly where Tony is likely to be in his comfort zone… I take a markdown file, I drag in onto the browser and boom I have a site. But from a UX point-of-view it can grow arms and legs very quickly… especially with all the versioning etc.

So, we’re starting as basic as we can go (some directories, with some text files and some images), and moving on from there.