In the server world I agree you would just provide a bridge, much like IPFS have done with Cloudflare, and this is a little simpler, but not that much really.
The downside is that you are now using servers again, with all their vulnerabilities and difficulties. I’d rather not go far into this in this topic (happy to do so elsewhere), but one of they key points about SAFE Network is that it eliminates servers as we know them, and this is one of the reasons it offers data security, privacy and above all greater ease of adoption and use: no server to buy / install / maintain, no pod service provider to trust / get taken over / switch business models, no bottlenecks vulnerable to overload / hacking / surveillance / DDoS etc.
From the user’s point of view not having a server involved is more secure, easier to adopt and to pay for (no subscription - you pay to store when you upload, no domain renewals, no need to ever switch service providers or migrate data).
Also URIs are permanent unless the owner chooses to redirect them, but even then the old versions remain accessible so as a culture we get a permanent web.
If you keep the traditional server in the loop, you lose those benefits. I don’t doubt people will also support that approach (servers as a gateway) but I see it as more of a problem than a solution because users may think they have the benefits of SAFE, when in fact very important features have been lost.
If you want to go deeper maybe we can spin off a new topic or chat elsewhere, and link to that here?
For folks who might want to deploy or pull my Plume code, please now pull the default branch gh-pages rather than solid-auth-client-smalinin. The default branch now has the working code (including changes suggested above by @A_A) and I’ll continue work on the latter.
So you can now just git clone https://github.com/theWebalyst/solid-plume to get Plume and follow deployment instructions here (now updated).
What would be useful is making Plume adhere to established “best practices” from the Blogosphere era e.g.,
RSS and Atom Feeds
Feed Discovery patterns via xhv:alternate relations in HTML metadata.
Those are the items we haven’t been able to address, due to our current bandwidth.
Why are those features important? They provide a nice bridge to a large community of folks that are trying to resurrect the Blogosphere – which offers a much more democratic and open approach to news and journalism as a whole.
Agreed. I’m still not clear on the status of the code in Sergey’s fork, why login doesn’t work and so on, so without any response to my questions I’ll be continuing my own fork (although slowly! also due to bandwidth ). I’ll remain open to collaboration from anyone, and happy to issue PRs to any fork that wants my changes. For now though I’m doing other stuff.
@A_A do you (or anyone here) have any thoughts on better ways to deploy the Plume files? I was going to see if solid-filemanager can unzip files (as I see it can zip them) but haven’t had time to try it yet.
Better still would be a deploy to pod script but I don’t have time to work on that yet. I think that would be of general use and could be bundled with different apps.
Any other ideas spring to mind?
And to everyone: PRs on this and other issues very welcome. Plume is a great little starter app for newcomers, so I think even though it is old (pre LDflex code) it is worth getting it to a decent usable, easily deployed state.
Alternatively someone might like to rewrite it or make an equivalent simple blog app using the Inrupt SDK? That would be a nice project.
I’ll be happy to see any of these, and to help out where I can.
Its great what you’re doing with Plume. Recently I remembered https://mavo.io/ which extends html in a way like web components, but it has the advantage of having no dependencies, some nice demos at https://mavo.io/demos/ , and a way to extend it with backend plugins. It could also be used to make blogs. Ruben Verborgh wrote a Mavo backend for Solid a while ago. I dont know if that still works, but its at https://github.com/solid/mavo-solid . Currently there is a limitation that a backend can use only one resource specified in the html with the mv-storage attribute. If mavo-solid could be updated and/or Mavo itself could be modified to allow multiple and inherited mv-storage attributes, that would I think be a great project if someone is looking for one. I’m thinking about it and if it makes sense (and I can get up off the couch) I’d be happy to contribute to that.
Something I am not sure about is, how to handle the .acl file. Because the solid-filemanager doesn’t display such files and therefore I’d suggest to either configure it before zipping and uploading or (my preferred solution) upload the zip and .acl file separately.
Apart from that I would suggest to zip it and let the user upload and extract it via the solid-filemanager (right click -> Extract here). This would also make it easy for the user to select the storage location.
For the future, I am planning to implement a file transfer between pods in the filemanager. So you could upload it to a public folder in your project pod and the user simply copies it to his/her own pod. And regarding the .acl files: I haven’t really looked into this yet, so maybe there is something I can do about them too (a permissions menu would be cool, but dunno if that is possible). But both of these are still only under consideration.
And I’ve also thought about creating a deploy to pod script but this could be inconvenient to use for non-programmers (and also coding language specific). Therefore I’d suggest to do this via any kind of web interface, which could have a nice user experience and is platform agnostic. I think it would be nearly sufficient to copy files from one pod to another for installing apps. But I agree that for programmers a script could be convenient. If it’s only uploading it should be easy to do though.
And if you want to start a longer discussion, we should probably move this to another thread
Here is our repo with the code properly merged. As for your “commercial investment” comment, is that necessary?
I’ve told you repeatedly that we couldn’t prioritize cleaning up the repo if nobody was interested in it. Now it appears folks are, so the repo has been cleaned up.
It wasn’t meant to offend. I was confused and speculating as to why you hadn’t responded to my question, and then posted that long post revealing that you had working code, yet still didn’t clarify the things I was asking about and accused me of misrepresenting the situation. I think we could both reflect on our communications.
I apologise for misunderstanding the situation and the offence I’ve caused by that remark.
I’ve told you repeatedly that we couldn’t prioritize cleaning up the repo if nobody was interested in it. Now it appears folks are, so the repo has been cleaned up
I don’t think this is accurate or helpful so will just thank you for cleaning up the repo, but as you know from the Solid chat I’d already resolved the issues with help from Ruben Verborgh today. So unless you repo has additional functionality now, my fork has already moved ahead of it (with unpushed maintenance, tidying and bugfixes).
I remain willing to look at how we can combine forces and maybe develop a reference repo, but I’m not seeing my offers to do that reciprocated so I’m going to assume we maintain different forks and can merge individual features ad hoc. That’s fine too.
I am though aware that I may be diverging from some of the intentions for the original code because I don’t know what they were!
I think the .acl file should be deleted.
It is inherited, and eventually modified using the rainbow pane of the plume folder. The actual way to import is extremely dangerous. Personally I locked the folder with a mistake. My bad
The distribution of the file without any .acl file can be made as a zip file imported with the AA solid-file manager :
** unzipped in place
** and edit the config with it
I agree it is a problem now, but the solution is to prevent the owner a of from being able to lock themselves out - ie in the server implementation.
I’ve already removed the acl file from the folder to make this safer, and replaced it with a template. It doesn’t solve the problem entirely, but includes instructions and a warning in the file itself.
At the moment users can still mess things up by editing or creating.acl files - and I’ve also done this - so I think the server needs to provide safeguards, and a way to recover access by the pod owner.
FYI, @RubenVerborgh knows what we’ve been doing with Plume etc… Our goal was to progressively make all the apps built by Andrei work with the new Solid Authentication Layer.
Moving forward, are you going to address new features such as:
RSS and Atom Feed Generation
Use of POSH (Plain Old Semantic HTML) for Feed Discovery
Those are important features missing from Plume right now.
It is currently needed but I could probably remove that need in order to get rid of it. I’m not sure when I’ll be able to do that though as something has come up.
My aim has been to get Plume working, easy to use and deploy, and updated to use the current auth API. I have almost completed all that and will merge the changes to gh-pages when I’ve tested on my pod. At the moment I accidentally put them on the wrong branch, but [now fixed so] they are pushed if anybody needs them sooner.
I’ve now completed my update of Plume for the time being and provided a simpler deployment path and tagged the release as v0.10.
Status and Changes
Plume is now fairly easy to deploy and very easy to use. All you need is a Solid pod, although it is also easy to deploy it to a separate web server.
I have not added any features. Instead this update is focussed on upgrading Solid to use the latest Solid API (rdflib.js and solid-auth-client), fixing bugs, and streamlining the user experience during first use, post creating and editing, as well as for blog visitors.
I’ve updated the README and provided a Deployment Guide (on my own Plume blog instance).
Please report any problems and bugs either under github issues or on this topic.
Notes:
@bourgeoa I’ve removed the need for a .acl file as you suggested. Thanks!
I’ve been thinking I might make one more small enhancement: adding metadata to the HTML for link previews (eg when you share a link to your blog on twitter etc). I’ll look into that a bit. I was helped by an interesting chat with someone using a link shortener, which I suggested he reconsider due to privacy concerns. He was doing so for aesthetic reasons only and went into it in some depth for which I’m grateful because he’s pointed me to how to provide this feature. In the end he realised using a link shortener didn’t do what he wanted and has stopped using them. Win win!
@rom. Seems that the login flow works for your blog… but once i’ve Authenticated using my solid community id I get a not authorized on the url you’ve shared. Sharing my experience in case this helps any debugging efforts.
@rom hey, that’s cool. Thanks for giving it a try. I will need to look at the guide again because it may be possible to improve it so this doesn’t happen so easily.
No, this is because you didn’t deploy it under ‘/public’ (an easy thing to miss in the deployment guide as there are several steps). You either need to do that, or make sure the Plume/blog directory is readable by anyone.
You can fix this by changing the permissions on your ‘/blog’ directory to give read access to everyone. I’m not sure exactly what the steps are to do this, but if you login to your pod, browse to your root folder (‘/’) and then to ‘/blog’ you might able to set this in the Solid databrowser UI (maybe using the ‘rainbow’ icon). But as you now have Plume there this might not work - actually, thinking about it, I’m pretty sure it won’t but let me know if you try it. You would need to use solid-filemanager to disable Plume first, by renaming the /blog/index.html file to something else (eg index.txt) temporarily, and then changing it back after you make the directory public.
Can anyone confirm that it is possible to change permissions this way, and give more precise instructions?
If not we can set up a ‘.acl’ file for it together, but that’s tricky so I suggest waiting for help. I’m doing family stuff over the holiday but might find a moment.
@einsty thanks for the report. What you reported is expected because you don’t have read access to his /blog directory.
). I’ll remain open to collaboration from anyone, and happy to issue PRs to any fork that wants my changes. For now though I’m doing other stuff.