Solid Plume - simple blog app

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.


As an aside, I have tasked my students with creating a blog app for Solid (around 20 groups of them, so 20 apps). Possibly good projects could some out of that.


And this just dropped in my lap in the SAFE forum. It’s actually intended as a way to evaluate frameworks, but instead of TodoMVC they have a Medium clone.

Still trying to get my head around it, but it could be an option for a Plume replacement, since it is a ‘real world’ app.

Problem solved!

It would be interesting to see how easy it would be to a Solid backend for RealWorld . A student project maybe :wink:

1 Like

What do you think of solid/blog-app chat channel to exchange between your students group and solid community ?
Same has been done with solid/chat-app.

Very interesting, especially:

See how the exact same clone (called Conduit) is built using any of our supported frontends and backends. Yes, you can mix and match them, because they all adhere to the same API spec :open_mouth::sunglasses:

because they work through a common API. With Solid, that API is LDP + data shapes.

Hard, because they impose an API:


Looks like I’m late to the party with this having just skimmed this thread but it looks nice and I just tried to install and have a play. I’ve got the files unzipped into public/blog/ but when I visit https:///public/blog I get a download of the index.html rather than it displaying in the browser. Any ideas why that might be?

This is my config:

    "owners": [
    "title": "Plume (theWebalyst)",
    "tagline": "Light as a feather",
    "picture": "img/logo.svg",
    "fadeText": true,
    "showSources": true,
    "cacheUnit": "days",
    "defaultPath": "public/posts",
    "postsURL": "https://<mypod>/public/posts/",
    "postsElement": ".posts",
    "loadInBg": true

This sounds like a problem with the server, possibly a bug introduced by one of the server upgrades. Can you find out which Solid server and version is running and open an issue for it?

I don’t think it can be a problem with plume.

Am I correct in thinking you are not using to host your pod? As you can see that server should work:

Thanks for your reply. Actually I did try it on solid community. Maybe I made a mistake somewhere. I’ll poke around and see if I can figure it out.

1 Like

In that case the only thing I can think of is that the file isn’t index.html (all lower case) but I expect you would have noticed that!

I’m not sure what else could cause this behaviour. Might still be worth raising an issue as it is the server side which is deciding to serve the file as text rather than HTML. I don’t know why it would do that though.

Did you use solid-filemanager?
Is it the same as

1 Like