Solid Plume - simple blog app

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 who was using a link shortener on twitter 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 add the metadata for previews. In the end he realised using a link shortener didn’t do what he wanted and has stopped using them. Win win! :slight_smile:

See forum discussion on Web Metadata for publishing

Yes it possible to change the permissions with the rainbow pane. It has to be done by the pod owner.

Anyhow the best is to delete the actual plume and to reinstall it under /public at least for the /posts folder.
The webapp can be anywhere. I have it on an other web server (a non Solid pod one).

This isn’t necessary. The posts will be under /public by default, wherever you install Plume.

So it should be possible to rename the index.html, change the permissions to ‘read by anyone’ as described, and then restore the name of index.html.

You can of course do as @bourgeoa suggests and just install Plume in /public/blog instead, because that will be readable by anyone, by default.

Thanks. Still continuing to debug.

Thanks. I tried moving it, but still no go. Will try to reinstall later and see.


Hi, just wanted to report that I got it working on my private pod after some hazzle with the installation - and it looks really nice, good work!

About the hazzle, I’m not quite sure what’s going on but I started by uploading and extracting the zip file (using solid-filemanager) to a folder under the public section. Then I moved the folder to a new name (public/blog) as I had forgotten to rename the zip before upload, and updated config.txt to match the URL paths. Then I opened /public/blog to check if it worked, but the interface looked really odd and nothing worked. Scratched my head a bit and then took a closer look at the files, and noticed that many files and directories had been converted to .ttl files - which obviously broke the whole thing. I’m not sure if it was solid-filemanager or the solid server, or perhaps the default data browser which did this, but I kept the “broken” install folder for reference - this is how it looked:

LICENSE app config.txt css$.ttl favicon.png img$.ttl index.html js$.ttl manifest.json$.txt popup.html posts

Anyway, I decided to just do it the “oldschool” way - uploaded the zip file directly to the server, and unzipped the files into the public/blog folder, bypassing the solid servers file handling. And now it worked much better - the app started with myself already logged in (as specified in config.txt), and I could write a new post and admire the pretty result! :smiley:

I haven’t tested the rest of the plume functionality yet, but it looks promising so keep up the good work!

I also wonder how I may installed it in a more shared way - you wrote that the app itself can be anywhere, but in my experience (so far) it looks like solid apps works best when they’re hosted under the same domain as the pod. So two questions:

  1. If I install the app elsewhere, do the config.txt file still have to be on the app folder, or is there a way to configure the app from the blog folder instead, so it can be shared by more users/blogs?
  2. Does anyone know if it’s possible to share apps on the main solid domain, so all pod users on the same domain can use the same apps? This isn’t only for this app but in general - I’ve tried to figure out how to do it, for example by adding an apps folder in the data folder for the main domain. But getting ACL errors when I try to open them, and not quite sure how to set the correct ACL for the main domain (if it’s possible).

Anyway, here’s my test blog, if you wanna check if it works as expected:

1 Like

Hi @ztein, I’ve tried to reproduce your bug to check if the issue occurs in the solid-filemanager, but couldn’t reproduce the bug.
What I’ve tried:
-> Download
-> Upload it via the solid-filemanager to /public/
-> Rename the extracted folder to “blog”
-> Rename config-example.txt to config.txt and change owner and posts settings in it
-> Open “blog” in new tab

When opening it, everything looks fine and I can also create posts. Did you make something differently to achieve this behavior, or do these steps result in those .ttl files for you? Also please make sure to use the latest version of solid-filemanger (this link and also make a full refresh. Versioning of this app is still not very user friendly -_-).

1 Like

Hi @A_A, I tried a bit more now and can reproduce it. It happens when I rename the folder - after renaming those directories have turned into ttl.

But note that I’m running the solid-filemanager from the same domain, hosted locally - I’m not able to login with the online version, so downloaded it and put it into an apps folder on the same pod. Not sure if that makes any difference, but using the version I found here:

1 Like

Tried again with another file (the zip from solid-filemanager), and same thing happened now. It also looks like it’s the same files and folders that are converted to ttl: .json files and js + css folder. Isn’t that a bit odd?

That’s great, thanks for giving it a go and overcoming the early adopter hurdles! Credit goes mainly to Andrei Sambra for the app, with bugfixes, updating and tweaks after that by Sergey Malinin/@kidehen and myself.

The hazzle looks like issues with the solid-filemanager / server interface. I note that the symptoms are similar to a problem I had trying to get Plume to write to a ‘.json’ file. In the end I switched to ‘.txt’ to avoid that (although I’ve subsequently removed the need for Plume to write the config). It seems to me the server is either not getting the headers it expects, or is just not behaving as it should. My guess is the latter, so it may help to know what version of server your pod uses, but I’ll leave that investigation to @A_A if that’s ok with him! :slight_smile:

If I install the app elsewhere, do the config.txt file still have to be on the app folder, or is there a way to configure the app from the blog folder instead, so it can be shared by more users/blogs?

Plume requires config.txt to be in the app folder (i.e. along with index.html). You can add other authors to it, although I have not tested this. It might just work, so by all means try:

  • add WebIDs to the owners setting (as a comma separated list)
  • ensure each of those WebIDs is given write access to your /public/posts directory.

You can also relocate the ‘posts’ directory if you want it elsewhere by setting the full path as postsURL in config.txt, but you will have to make sure the folder is readable by anyone, and also writeable by each of the owners.

If you try the above it would be great to hear how you get on!

Does anyone know if it’s possible to share apps on the main solid domain, so all pod users on the same domain can use the same apps?

I think this is quite tricky so in my limited update I haven’t thought about it much. Maybe it is something that @kidehen knows how to do?


Yeah sounds like the same problem, and also happens with css and js folders on my server. I’m running Solid server (v5.0.1) inside a docker container, with apache2 proxy in front.

1 Like

@ztein Could you change the copyFile method in src/Api/Api.js to following and try it again?

export async function copyFile(originPath, originName, destinationPath, destinationName) {
    const fileResponse = await fetchFile(originPath, originName);
    const contentType = fileResponse.headers.get('Content-Type');
    const content = (contentType === 'application/json') ?
        await fileResponse.text()
        : await fileResponse.blob();

    // Note: Not passing contentType as parameter as this would lead to errors when creating .json files
    return createItem(destinationPath, destinationName, content);

I can’t reproduce it with the version (I think it’s NSS 4.x.x, so it’s probably an incompatibility with NSS v5.x) and don’t have a v5 pod for testing it so it maybe fixes it and maybe does nothing.

And could we move this bug discussion to github or the forum post so we don’t litter this thread too much?


Discussion on Web metadata for Plume:

If you could run posts through a part of speech tagger like , and then put the results in an RDF graph, then they could be available for SPARQL update queries which could add tags that depend on concepts in the text.

1 Like

Plume v0.11

A minor update: Plume now includes basic semantic metadata when displaying a blog post. This is inserted into the DOM programmatically so you can’t view it using ‘View source’ but you can see it using a tool such as @kidehen’s excellent Structured Data Sniffer plugin for Firefox.


Also bugfixes.

  • remove spurious ‘#’ appended to post URLs, which were also messing up saved post RDF/Turtle
  • fixed browser tab titles (which were not showing the post title)


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’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.

1 Like

So this is a new feature added to your fork?

Adding RSS feeds for posts and exposing said feeds via metadata is a critical piece of functionality that Plume needs.

Why? Because it will contribute to bringing key bloggers and others from the blogosphere over to solid etc…

BTW – Nice seeing you put our Structured Data Sniffer to good use :slight_smile:

1 Like

It’s a long while since I did this, but I’ve done a little reading and it is coming back. A basic feed is just a matter of generating an XML file listing the articles on the website I think.

Is that your understanding, and is that what you have in mind?

Yes, and XML file is generated and then exposed for discovery via xhv:alternate relation in POSH (Plain Old Semantic HTML). Naturally, you can duplicate the relation in RDFa for tools that grok that.

Last night I thought, yes (@kidehen) I’ll be able to implement an RSS feed quickly and was planning to do it today, but overnight my brain was still active and early this morning lead me to some other conclusions, including on the future of Plume.

TLDR; I think we should just maintain Plume and make only minor enhancements, while creating a Plume 2 from scratch in order to meet the need for a better blogging platform. I’ll come back to why I think that shortly.

Feature: RSS Feed

Firstly I realised that there was no point implementing an RSS feed without first implementing support for draft posts. At the moment we get away without this because there is no automatic distribution (RSS). People work away on a post and once it is ready, they share links to it manually. You can’t have the first draft going into the feed, so you would also need a way to create and manage draft posts, publish them, edit and update.

That’s not too hard. In the early hours I had some of the details worked out and was going to at least document this, although it was more work than I can do in a day. I know the Plume code fairly well just now, so I can see how to do it, but it is a few days work (for me).

Feature: Deploy Plume Automatically

Inspired by @jeffz’s recursive copy and @A_A’s solid-filemanager, I’ve also been thinking about making deployment of Plume automatic (ie a blog visitor can click “Deploy Plume”, identify where to install on their pod and click “Install”. This would also allow automated updates).

To drive adoption this feature goes hand in hand with things like draft posts and RSS, but doesn’t depend on them and I think is probably easier. Plume is in a state now where copying/unpacking the files to a suitable location and creating a config.txt file there is enough. Such a feature would improve take-up a lot. So for me that would come before the other enhancements and is something I’d consider doing, or help someone to implement.

Plume’s Future

However, coming back to the first point - why I think we shouldn’t build much on top of the exisiting code…

Plume wasn’t written to be extended as far as I can tell. The code is fit for purpose (a very basic blog). There is code there that I don’t understand, and I can see some extras were being considered, but I have not been able to figure that out or find information about ongoing plans. But in any case, IMO the code is not suitable for building significant new functionality. It is not well structured, making it hard to understand, hard to modify without introducing bugs (I fixed at least two introduced by Sergey as well as earlier ones I’d fixed when I did my original demo of Plume on SAFE), and I’ve found this myself each time I’ve worked on it.

At the very least it should be restructured, made modular and split into smaller files, but the current approach is also clumsy and slow and will not handle additional functionality without an increasingly poor UX IMO. So if we want to build a better blog, I don’t think the existing code is the place to start.

Adding RSS without draft posts would be fine (but poor for publishing). RSS with draft posts would be manageable too, but each new feature will likely break things and so be ‘expensive’ to implement, degrade the UX (it is already clunky and slow), and make it harder to maintain or extend.

So I think it would be better to start again with a suitable framework such as React/React-static or even something up and coming like Svelte, and design the architecture with an extendable foundation, starting with functionality similar to what is there, and then building on that.

My Plans

This means I’m planning to stick with only minor enhancements and maintenance at least for now. I’d like to add the “Deploy Plume” feature because I think that is sufficiently separate from the existing functionality to do without doing more harm than good, and I think it would be a big win in terms of helping new people interested in Solid getting a useful app up and running. I need to focus on other projects for now though.


Indeed, this has also been my impression of a couple of the older Solid projects (also Warp, for instance). The code is not too maintainable, to the point where it is sometimes easier and more sustainable to have a new codebase.

Also, Web development has evolved in the meantime, and we are designing new developer experiences, which make it easier to create apps in the first place.