upload and extract those files to directory under /public in your pod
edit the configuration file to identify yourself as owner, and provide the location for Plume to store your blog posts
when you first log into Plume it will create the post storage directory and a welcome post to help you get going.
that’s it, happy blogging!
In the past I adapted Plume to show how Solid apps could be supported on SAFE Network, but that was a bit of a SAFE specific hack shown at the SAFE DevCon 2018.
This release instead builds on the original Plume by Andrei Sambra
and some of the improvements made by Sergey Malinin (of OpenLink), although that fork and mine have begun to diverge. I understand that OpenLink intend to enhance Plume at some point, so I shall continue to try to work with them so there is an easy way to deploy Plume, whichever fork is best.
The history of Plume and how it was developing is unknown to me, but I’ve got a bit of a feel for that from its features and studying the code. I still don’t see quite what was being aimed for in terms of people deploying it, why browser storage is being used for config and so on, so I have done my best to provide a simple blog that is easy to deploy and use.
Comments and feedback are welcome but I’m time limited so may not be able to do much more in the short term, but if you have knowledge of the original plan please let me know.
If you want to help, yay! You can follow my work on my fork at solid-plume.
Plume is currently using browser storage to save and load its configuration, I have left this in place for now, but may deprecate this and possibly remove it altogether as I’m not clear how that is supposed to work for visitors or multiple authors. Or even for one author as it ties settings to a given device + browser. There may be some things that are useful to have in browser storage, but they may need to be added back in later.
List of Plume blogs
Add a link to your Plume blog here (editing this post is open to everyone):
It sounds like a really nice project I will follow with interest
Here are a few thoughts from my side:
First of all, does storing it as RDF make it decoupled from a specific rendering? If yes, are there already useful RDF Blog readers available?
Secondly, would it be possible to also give the ability to save it as RSS? Because I guess that many people currently use RSS Blogs and therefore the readers for those are more advanced. And giving both choices should help getting more users from my point of view.
And finally two points about the initialization process: For deploying I would find it useful if the stable versions are packaged as zip files, as this could easily be uploaded to the target location and then extracted. And for setting up the config file, I would suggest to use a short step-by-step wizard which guides the user through this process. Even if it is easy, I think for non-tech people such config files seem a bit “scary”. In contrast a step-by-step wizard with short explanations increases the confidence to change something without breaking it.
Yes! The posts are stored in a folder as Turtle files. The content is stored along with other triples in markdown format. Anything can read them and render the triples and content as it likes.
If yes, are there already useful RDF Blog readers available?
I don’t know. It would be useful to know if anyone is aware?
Secondly, would it be possible to also give the ability to save it as RSS? Because I guess that many people currently use RSS Blogs and therefore the readers for those are more advanced. And giving both choices should help getting more users from my point of view
I think this is a good enhancement, but for later. Similarly with your suggestions about deployment and configuration. I think it is feasible to include a ‘Create your own Plume blog’ feature that automates this, but it isn’t planned and I’m not likely to tackle that myself for a while at least.
I made good progress yesterday and have fixed a few things so I hope not much more to do before this will be working.
I think Plume will make it fairly easy for anyone to set up a basic blog on their pod given clear instructions - to be written! - and a bit of help. But I agree that making it automatic with a wizard or something similar would be very desirable.
I agree with you, that these points are not on the top of the priority list. They all aren’t necessary to make a working version, but could enhance the user experience (and hence get it more widespread), once it is stable.
I’m enthusiastic about the idea of Solid on Safe, because I don’t want to rely on a pod provider or host a pod myself. So far I guess I’ve sort of glossed over the details, and now I’m wondering more about it. Sorry for the ignorant questions, but could you explain more about how it would work? I’m thinking of Safe as sort of like distributed and secure storage. Would having no servers mean that you take solid client apps or libraries one by one and convert them to work with safe? Or instead of a node solid server, would there be a safe solid server that would match the nss api? I guess I can’t get my head around the idea of having no servers.
The way I’m tackling it is to create modified versions of Solid libraries which allow a Solid app to ‘just work’ on Solid or SAFE.
For simple apps like Plume and solid-filemanager, no code changes are needed - just swap in the replacement library (rdflib.js or solid-auth-client for example). When deployed on SAFE the app thinks it is using a Solid server, but it is actually talking to SAFE - the libraries provide a Solid LDP interface for SAFE Network.
The same library can work on Solid or SAFE because they use different Web protocols (http:// and safe://). So the library looks at this and can see whether it is being used on the Web or SAFE Network.
There’s a ten minute screen cast which shows how this works with Plume from my SAFE DevCon presentation here (also a link to slides).
Yes, but the changes to those libraries are also trivial (mostly just redirecting fetch()) because the work is being done by the LDP emulation in SafenetworkJS. The latter is still a work in progress but handles common app operations.
Great, your testing is very welcome. Most of the work had been done by others, I’ve just run the final few yards to get the basics working. There are still bugs to fix, but I think fairly easy ones now.
If you and anyone else set up your own Plume blog, please post the links here and add them to the OP (it is now editable by anyone).
I’ve tested it out and I have to say, that I really like the user experience
Once it’s deployed it is really easy to use and also looks nice.
Regarding the setup, here are some things I’ve noticed:
(1) The git clone command you suggested didn’t work for me. I’ve used git clone -b solid-auth-client-smalinin --single-branch https://github.com/theWebalyst/solid-plume to copy this specific branch.
(2) When releasing, I would remove (or comment out) the tester section in the .acl file
(3) In the guide it says to edit the config.txt file, but only a config-example.json file exists. (I’ve copied it to config.txt and edited it then)
(4) The .acl file might be hidden in a file manager. When this process is the same after the release, I’d suggest to mention this.
(5) The default posts location in the config-example.json file is /posts instead of /public/posts
Thank you for connecting this app to Solid, I really like it!
We added Plume as a default application to our Node Solid Server (NSS) as part of an effort to simplify the use of Solid by ensuring availability of a simple to use Default Application per instantiated Solid Pod.
Note, the work on Plume has been overseen by me personally. It didn’t seem be generally interesting this time last year. I am happy to see its importance is now increasingly understood and appreciated.
BTW – There are many other applications that need similar treatment, so the more participants the merrier.
I’m now confused @kidehen that you pointed me to code that I have spent days fixing up, when you already have Plume working. I also asked the status of the code, but got no response.
It would have been fine to explain you had it working, but didn’t wish to share it because of your commercial investment or whatever. But now I have it working, you post all this. I’m not sure what your point is in doing this now.
@kidehen You pointed me to some code by Sergey, I asked its status to help me use it or get it working but got no response. If you read this topic, that and the work I subsequently did is correctly represented. For example I’ve stated earlier in the topic that most of the work was done by others with me just doing the ‘last few yards’. I even used Sergey’s github name in the branch name (solid-auth-client-smalinin)!
So I’m not claiming credit for anyone else’s work - but I take it you thinking that was the case is the reason for your long post above?
I was just surprised that you now posted all this information because it would have been very helpful to have known you had it a few days ago, and would have saved me days of work to have access to working code.
Clearly there’s some misunderstanding here. Perhaps you or Sergey would like to take over and help others deploy your working code?
I’m happy for you to do that, I just wanted a working Plume for my own use, and to help others do the same.
I’m also happy to continue with my fork and you can use my changes if they are useful - but I assume you don’t need them.
I asked for a way to contact Sergey (also earlier in this topic) as a courtesy and so I could complement him on his code and his integrating solid-auth-client which I was not feeling competent to do. I still don’t have the login popup working properly (I posted about this on gitter but have had no replies), and there are other bugs in the repo you pointed me to (unless I have introduced them!)
It would be good to clear up the status of this code and make it clear for anyone who wants to extend or deploy Plume how to go about it. So by all means take that on, or if not let me know if you want to collaborate etc.
If not I’ll carry on with my fork and documenting it for others to use.
It is an interesting approach using slightly changed client libraries, but I think, I’d prefer another solution. I would leave the client apps untouched and use the logic of SafenetworkJS on the server. This is in my opinion a more generic solution, the Apps must not be build with different variants of the libs and must be deployed only once. For the app a SAFE-backed server would looks the same as a “normal” one.
What do you think about this approach? Am I missing something in your solution?