Phantom: a publishing tool enabling users of the SAFE Network to easily manage websites

[Shane]

Open source code repository
Most recent update
Live SAFE network URL

Please note that development of the application is currently in progress and pending the release of the next SAFE Network Desktop App version which contains some dependencies. As such, safe://phantom probably won’t work for you for a few more days and will just display a blank page.

Announcing Phantom, a publishing tool enabling users of the SAFE Network to easily manage websites. Phantom is designed to live entirely within the SAFE network, allowing users to create and manage websites and blogs without ever being exposed to the clearnet.

Phantom is built on top of the browser NodeJS libraries, enabling app level functionality without having to install a single program. All you have to do to use it is go to safe://phantom in your SAFE network browser.

Schedule

I’ll aim to post an update in here every Wednesday with the results of the previous week. Code will be updated much more frequently (expect 2-3 commits per day on days where I’m not working and 0-1 on days where I am.)

I work as a mental health support worker (I’ve recently changed career from IT) so it’s unfortunately shift work and I don’t know when I’ll be working until the end of the prior week, so I can’t provide a more concrete schedule than that.

[Shane]

The first project update:

Code

In the past week, I’ve achieved the following:

• Ported from Svelte to Vue, as I’m more familiar with it
• Began to mock the SAFE browser API so that I can test directly in Google Chrome
• Added a caching layer
• Added the creation of FilesContainers
• Added the creation of NRS
• Created an RFC to fill in some missing browser functionality: RFC0060 - Enable creating and modifying of FilesContainers within the SAFE browser environment

End user experience

In terms of user interface, the following screens have been added. (These are all fully coded, these are not Photoshop mockups, but screenshots of actual code running in an actual browser)

We don’t have a home page yet, so it defaults to the NRS domain listing page, once we have more of the app built I’ll add a nice home page, but for now it would just be grandiosity for no reason:

You can create a top level NRS (it defaults to using the default www sub name at the moment, since that’s what the majority of people will likely be using, but I’ll be adding the ability to manage sub names in the next week.):

You can select which domain you would like to edit the posts for, allowing users to manage multiple websites from within the web app (when you create an NRS, it will default to editing that one, I’ve set this up just to show you):

Once an NRS is selected, it will default to that NRS until changed - even between refreshing, restarting your PC, etc.

A lot of the design work here is wire-frame-ish and is subject to change.

Design decisions

It’s important to me to reduce the amount of dependencies both in this website and in the websites generated by it.

I’m probably going to be doing something like the following:

• The websites generated by the app will be single-page-applications, using hash routing (why hash routing? It means that each post doesn’t need to be re-updated if there are any backwards compatibility changes, or changes to themes, or plugins, etc. A central store of code in the root of the public name is much easier to manage within the SAFE network).
• this will probably be something which can be optionally disabled (by people who understand the PUT / GET cost ramifications, and the performance costs), but seems like a reasonable default.

I’d really like it if the Phantom website itself was less than 180kb fully downloaded (as a single page application, containing all CSS, JS, HTML and woff2 files required for the entire app to function). I’m not using any images, only using a single font (OpenSans, and only Woff2 files since they are nice, tiny and supported by all the target browsers), and cutting out any unnecessary dependencies - even if it means more effort from me. The first websites on the SAFE network need to load blazingly fast to overcome any potential scaling issues in the future.

[happybeing]

Looking good Shane, no time to play yet unf. One thing you may have missed is the epic discussion we had on terminology for ‘domains’ on SAFE. I’m not 100% but think we decided to avoid ‘domain’ and use ‘NRS Name’ - someone can confirm or correct this as I might be misremembering. There is a terminology topic which might be useful but I can’t find it! ← I found it but it doesn’t help with this.

[Shane]

Honestly, I would love to, but I’m always worried people won’t understand me if I start taking about NRS names and sub names. I really wish it had a snappier title. I’ll change it in the app to NRS names, but it’s at the protest of wishing we had a better option.

[Josh]

@Shane you were previously streaming your work on SAFE projects, is that out the window?

[Shane]

Not at all, I’ll see what I can rustle up, but it won’t be for a few days at the least.

[Dimitar]

Thank you for the work you do! I can’t wait to migrate my sites with Phantom on SAFE!

Do you know that the forum has a dark mod? I forgot how horribly bright it is without it…

[Shane]

I believe there is a CSS media query you can use to detect dark mode nowadays, I’ll have a look at implementing it, just for you, @Dimitar

[Dimitar]

yes, I am very concerned about your eyes … i want Phantom as soon as possible

[upstate]

It’s great seeing you back working on a project for the SAFE Network!

Thanks for all your time and effort!

[Dimitar]

Thank you once again for the work you do @Shane!

I will post translations in Bulgarian for all updates you post

https://forum.safenetwork.bg/t/phantom-instrument-za-upravlenie-na-sajtove-v-safe-mrezhata/110?u=dimitar

[Shane]

Evening all, I wasn’t expecting to have another update so soon, but I couldn’t sleep tonight so I smashed through some work instead.

At the moment, most of these calls are mocked, so the safe://phantom website won’t be functional - I’m waiting on a couple of very minor updates in the next week from the SAFE development team to unblock me (and anyone else doing SAFE browser-based development), so while what you’re seeing has all been coded in entirety, the underlying SAFE network libraries are all using mock data for my own testing purposes.

New features

There is now a posts listing page, accessible after selecting an NRS to edit:

Creating a new post takes you to the post edit page, where basic markdown is now supported, including a live updating preview (very similar to the safenetforum editor, only bigger). I still need to add support for anchors, blockquotes, code blocks and images. I’m actually quite proud of the markdown → HTML formatter so far, I’m just very happy with how so little code is accomplishing so much. Normally, when I write raw Javascript it ends up a horrible mess, so I guess it was a good night for me.

At the moment, the save post / publish post buttons do nothing, but all the Markdown → HTML work has been done, so making those work will be minor, I just need to do some more mocking work first to enable it.

And here is the post listing page if you click the back button:

Design decisions

I’ve decided that posts will be stored as raw markdown, with a small amount of HTML issuing a REL canonical, at their respective post URL, for instance:

• Accessing /#/post/draft-post will show you the webpage with all theme styling, javascript, etc.
• Crawlers can simply load just /post/draft-post which will contain the text-only markdown version of the page, but the canonical URL will point to: /#/post/draft-post

This means that despite it being a single page app, crawlers shouldn’t have any issue indexing the content of the website.

I mentioned in the last update that I was targeting a 180kb download for the entire Phantom application (all pages, all CSS, all Javascript, etc), and at the moment I’m doing pretty well:

Compressed, I am totalling 67KB, + 44KB of font files, so 111KB, uncompressed I am totalling around 230KB. I’ve managed to get it so small by being absolutely ruthless with dependencies, at the moment I have no dependencies which aren’t required for VueJS to function (for instance, writing my own Markdown parser as tersely as possible, writing my own SAFE network libraries, my own Promise library, my own cache library - with the position of caring more about code-size than ease of development).

I don’t see any reason why I shouldn’t be able to keep the compressed (what is sent over the network) size under 150KB and the uncompressed size under 260KB for the final project.

[Nigel]

looks great Shane! Will this be or is this mobile friendly? Would be fun to take it for a test drive on the mobile browser when it’s good and ready.

[Shane]

@Nigel it will be, but isn’t quite yet. I haven’t had time to sort out the SAFE browser on my phone yet, so it’ll be a few more days before I have a chance to test my media queries.

[anon28980808]

I’m really looking forward to all of your work.

What about the other dude named @AndyAlban? He kinda disappeared just like you did. Does he plan on rejoining and helping you again?

[Shane]

Andy is actually doing really well for himself these days - I went to a comedy show with him a couple of days ago.

He was my protégé earlier in his career and I gave him his first job in the industry. When my company was sold and I started contracting, I took him on again, and then when I joined Bunting as the Head of Technology, I hired him a third time as a software engineer.

He’s working at https://yozu.co.uk/ these days as a Ruby software engineer, with a bit of DevSecOps sprinkled in. We still talk about life, work and code almost every day - he’s going to be the best man at my wedding in Spring 2022.

As for whether he’ll join in, it’s unlikely, he’s just taken on a spare time contracting project so he’s swamped, but it’s open source so there’s nothing stopping him from contributing in the future.

[Shane]

Hi all, I know we only got an update a few days ago, but I didn’t want to leave anyone expecting something this Wednesday waiting.

I’ve made some good progress on the underlying structures used by the app in the last few days, although this hasn’t manifested as that many visual changes.

Screenshots

I’ve added support for images to the Markdown editor, and support for anchors. Of course, this also means support for anchors containing images. I still need to add code blocks and blockquotes, these aren’t that difficult, I just haven’t got around to it yet.

I plan to add support for image uploads in the next few days (as opposed to just hardcoding images) so you should be able to create and manage images from within the post edit page.

I’ve removed the “Publish post” button from the post editing page, in favour of having a “publish drafts” option on the post listing page. It seemed a cleaner / easier way to manage published website NRS versions.

Here you can see the post listing page. When you save a draft, it updates the FilesContainer. You are then presented with a “Publish drafts” button on this page which when pressed will update the websites version. At the moment, that doesn’t happen - because I need to add code to generate the blog home page (the post listing page). Expect this in the next update.

As I said in the last version, post URLs are indexable by search engines and are stored as markdown wrapped in HTML, with a corresponding canonical link. This gives you the flexible (and cheap) deployments of a single page app, with the searchability of a pregenerated website (what is known in the business as server-side-rendering).

I’ve been asked a few times about making the work responsive. The long and short of it is that I’m waiting on some API updates from the Maidsafe team before the project is in a deployable state where I’m comfortable testing it. As soon as I’m able to deploy and test it to an acceptable level, I’ll look at installing the Mobile browser and doing the responsiveness changes.

Background work

• In the last week, I finalised RFC-0060: Enable creating and modifying of FilesContainers within the SAFE browser environment, adding an extra option (support for HTTP Content-Type mime-types and charsets when updating Raw buffers to FilesContainers) and put it forward for review.
• I (re)discovered and reported a bug in the core API’s file synching code which was causing files not to be updated if the new size of a file was the same as the old size of the file.
• I spent a lot of time messing around with the core API, looking for edge cases where I could eek out more usage, or areas where the API left something to be desired. Expect more topics / bug reports to come of this, I prefer to create a topic when I’m sure something is a bug (mostly to save face), so this takes me quite a while to fiddle.

In short, the next update should contain something akin to the following:

• Enhanced Github flavoured Markdown support
• Generation of blog post listing pages
• The beginning of an inline image uploader
• Thoughts and idealogies around the support of themes, including the support of a subset of the Wordpress event hooks for familiarity, namely Actions and Filters, where there is a translation directly from server-side-wordpress to client-side-SAFE.

[wes]

This is an awesome project and initiative. Please keep up the great work. I’m excited to get to use this.

[jeremyjpj0916]

Your a friggen rockstar. SAFE is lucky to have someone tinkering around with it right now as much as you have even in this short window. Looking forward to Phantoms release in due time!

[Dimitar]

Hi @Shane,

can you provide a MAID address for donations?