UPDATE: v0.11 - Plume posts now have basic post metadata using RDFa / Open Graph / Schema-org. Also a couple of bugfixes, one important so upgrading is recommended. See:
Deploying Plume
The Deployment Guide explains step by step how to set up your own Plume blog. In summary this involves:
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!
Background
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 Implementation
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.
Progress Update
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!
Thanks a lot for reporting these issues. I guess I forgot to check in config.txt! And my clone command is indeed wrong. Iāll deal with all these points in a few days.
UPDATE: @A_A all the points/changes you made above have been incorporated, thanks again
Another way would be:
git clone https://github.com/theWebalyst/solid-plume
cd solid-plume
git checkout solid-auth-client-smalinin
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?
You can follow my work on my fork at solid-plume.
