Anything that requires the server for dynamic content will not be easy to convert. But simple sites should be easy enough!
There is at least one WP plugin already that generates it as a static site. That’s all fine and good, but if we also want to use comments (and/or any interactive content) and to be able to post direct to safenetwork as opposed to using a local install of WP and re-generating a new static site every time we have a new post; then using WP as a base isn’t very good and gives Shane nothing much to do!
consequently, I agree with Shane on this point:
Or perhaps as an app on the network you could authorize to publish on your site on the network.
As it develops features/plugins for interactive content could be added.
Heh. I’d have said it let’s him focus on something else.
But really. There’s still plenty to be doing …
Comments are write once and update the page, so like any page update (when mirroring only to safe from clear net). Which is definitely a worthwhile goal.
You could even inject code into the page to check if there’s a newer version and have that update automatically…
An alternative is having safe only pages generated from wp. Where the comment stream lives on the network. And thus you can comment from within the safe browser.
Something more complex arises when keeping a safe pages comments interactive and in sync with a clear net site. You can’t do this from the safe browser direct as http content is blocked… but you could (eventually) periodically update from a Server which checked safe…
There’s plenty of options. But I do think a basic static site -> safe with the cms already existing is very worthwhile .
I’ve been thinking about the comment system quite a lot, as it’s a simple CRUD aspect and works as a great entry point to what I’m considering as “Dynamic and Distributed SAFE Applications”.
I’m thinking of a flow similar to the following:
- The underlying comment data structure is an AppendOnly publicly shared blob per website page, where the owner is the website author and every user is granted write access by default.
- When a third party user tries to add a comment, it is appended to the end of the blob.
- Comments are loaded from the blob when the website page loads.
This would work, but it assumes that users won’t try to inject nonsense. A second option with more control for the website author would be a public append only map of files, where some sort of Cron processes the map in to a single blob. That way the author could delete spam comments and the blob would reprocess, but this introduces a third party (the person who runs the Cron service).
The reason for using a single blob is, of course, performance. It’s far better to do 1 GET than 25 GETs, especially when the network is in its infancy.
Could this be part of the same app for the website?, just running in the background on site-owners machine maybe? If so, could add features down the track to handle other interactive tasks like managing a web-store.
maybe not just a cron, but something that checks for changes. – edit: I guess that is a cron too, but something that happens constantly, not more periodically.
Thanks for the svelte referral. Vue is typically my framework of choice, I find it a lot simpler to get started with than React but just as powerful.
I was testing deployments to SAFE for size (which imho is a huge factor for the network, the more data being thrown around the more weight the network will be under) and was really impressed.
A simple application with a router, 3 pages and some network code cam in at 74kb in Vue and 9kb in Svelte, that extra 65kb is incredibly valuable, even if it means using a slightly inferior development environment.
So cheers, solid recommendation!
Maybe, but as soon as users start having to run and configure local services you lose the simplicity which this project is all about.
The safe network at the moment is geared towards techy people, and I’m trying to release tools to create a mass appeal.
Hopefully the network will at some point add distributed code containers, so the network participants themselves could automatically run the blob creation service, but we are a long way from there as of yet.
I’m not sure you need a cron process, but staging makes sense. This sounds similar to my thoughts in the past:
- a store that allows comments to be submitted by anyone, but doesn’t show comments on the site (but which can be reviewed by the site owner)
- the site owner is notified when there are new comments, and can choose to approve or reject them, with an option to add the poster to to a blacklist that hides further posts from those IDs.
My suggestion to look at static site plugins was to gather ideas and possibly code that can be adapted, not to use WordPress as a CMS for SAFE. To start it could be used as is, later it could automatically replace WP comments and other dynamic features with SAFE equivalents.
The point of that route is to help people get existing sites onto SAFE, while also allowing them to straddle web and SAFE if they wish (similar to dWeb Blog).
I think there’s a massive opportunity there and that it will naturally deliver a large number of adopters - millions of existing WP sites - to a SAFE based CMS. So it’s a route for somebody to create a very popular product.
PS I’m glad you like Svelte. Check out the Discord chat - always busy and very helpful. Always new components and examples being shared, usually an expert there to help etc.
What impresses me is that even though I’ve almost no experience with frameworks I’m still spending 95% of my time writing the code of my app, and very little trying to understand how to do what I want in Svelte. It’s so easy to learn and just gets out of the way. This makes using Svelte really fun.
Just a note here: You’d have to version your link to the comments code. Linking to an external NRS resource will break versioning (as someone could update the code without the site owner/user knowing). But that means getting a new version of the comment system is opt in for site owners. And can easily be rolled back.
Awesome, that’s actually much better. I like the idea of opt-in only upgrades. That allows people to control backwards compatibility breaks in data for more complex applications where a version update could cause data failures.
I’ve been tinkering on my end. I’ve ran in to some early issues with authentication within the latest SAFE Browser Alpha so I’ve moved off on to UI work.
@happybeing I’m sorry to say that after a few days of coding within a Svelte framework, I’m moving back to Vue. The bundle size is around 35KB bigger (once I realised I don’t need Axios since we’re using the underlying NodeJS libraries, and I don’t need a full router since I’m going with hash based routing, I was able to cut a lot of extra weight out).
I’ve ran in to a lot of issues with Svelte, namely how verbose the preprocessor’s output is for things like CSS class names and there being no easy way to opt out of scoped styles. Then issues with the routers available (the svelte-spa-router uses
use:active to automatically add
Svelte is really cool, and I think in a year or two I’m going to come back and have a fiddle with it again, it just doesn’t feel ready right now and it’s lacking a lot of the polish which make Vue and React so productive to develop in.
For everyone else: I should have some UI mockups to share with you all before the coming Wednesday. Tonight I went to the effort of mocking the
window.Safe calls I’ve used so far (I even added some code in to the mocks to randomly inject exceptions, so I can test the user experience against network failures), so I can develop against mock data until Maidsafe have a chance to investigate some of the issues I’ve raise.
I suppose you could consider this project
IN PROGRESS officially as of tonight, with a “watch this space” notice in place while I get reacquainted with my development tools.
Fair enough @Shane, you are a lot more experienced than me. I recognise some of what you’re talking about but I’m very little experienced with routers. It might be worth raising those issues in the Svelte chat - at least so they are aware.
They are pretty switched on so I doubt this will be news to them, although I follow things quite a lot there and don’t recognise the issues you mention being blockers - so just maybe there are solutions to some of this.
Good luck, glad to see you picking things up.
I’ve been struggling with Svelte myself today, found a problem using notifications within my imported JS files. Probably because I don’t understand the subtleties. Lots still to learn, which is what I enjoy doing. I’m keen to see what you create too and will follow with interest - and tempted to have a play with Vue.
By the way, I did some work with the new APIs and had authentication and a few other things working, so if it helps I could see if that’s still working. I moved onto a different project while I waited for the data APIs to be exposed again. The working code is in safenetworkjs (branch fleming-apis). That code is part alpha 2 (no longer working) and part new APIs (was working).
Small update, we now have a public repository to track the progress of this project: https://github.com/SAFEPublishing/Phantom
I’ve committed to making every line of code I ever write for the SAFE network open source, and any projects I create will be found under the SAFEPublishing group in github: https://github.com/SAFEPublishing, and making it as simple as people for people to deploy their own versions of the projects I create - so that I don’t have to be a centralised point of trust which could fail in the future.
@happybeing I don’t suppose you ever solved the problem of listing which NRS belong to a given user did you? At the moment the only way I have of testing whether or not a user owns an NRS is publishing a file to the FilesContainer attached to the NRS I’m testing against (similar to how AWS and other hosts have domain owners publish a TXT DNS record to prove ownership of a domain). It would be nice to be able to run a simple GET request against the NodeJS libs which lists a users domains, I even checked against the Rust libs in
maidsafe/safe-api/safe-api (because there are some functions in the Rust libs not yet implemented in the NodeJS libs).
…Although now I’m writing this, that sounds privacy invasive so I may have answered my own question as to why it doesn’t seem to exist - if so, just say and I’ll drop it and move on.
Also, I wanted to say a thanks to @bochaco and @joshuef for their help so far in getting me unstuck. SAFE is a ways away from being “developer friendly” due to how unstable the libs are, but these two chaps make it much easier to plough through.
Edit: The next post will probably be in a new thread, announcing the project officially and sharing some visual progress (since code committed and theoretical boundaries crossed don’t really mean much to the majority of this forum’s constituents).
Great news Shane.
You can/will be able to list the NRS names of the current account, but I think you are correct to assume you won’t be able to ask if a given name is owned by an account/user.
The details in this area are likely to change, but I did have some code that used the experimental RDF API to list the NRS names. But that was alpha2 and AFAIK the Fleming API for this is not exposed in the browser yet.
@happybeing gotcha, any chance you could point me to the right file? cheers
Yes this is correct, and @Shane, the labels feature set is what is being proposed as the way to achieve this moving forward. We used to have “default containers”, for this case it was named
_publicNames default container, and we used to keep track of NRS names in there, with labels I imagine you’ll have an API which you can say
fetch_index_filtered_by_label("nrs-name"), or even with a URL like
safe.fetch("safe:///nrs-name")…we’ll see how everything ends up shaping up but just to give you the context.
I can’t find it quickly, but don’t think it will help. As Gabriel says the API will be different when it becomes available.
Cheers for this, for the moment then, I’ll stick to storing them in localStorage and having the user verify ownership via automatically publishing a test file.