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.
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).
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.
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.
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 
What do you think of gitter.im 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 Medium.com 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
because they work through a common API. With Solid, that API is LDP + data shapes.
Hard, because they impose an API: https://github.com/gothinkster/realworld/tree/master/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": [
"https://<mypod>/profile/card#me"
],
"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 solid.community 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.
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 https://github.com/Otto-AA/solid-filemanager/issues/27
I’ve written an example copy app which can be used to install plume easily. It is based on the new solid-file-client which will hopefully be released soon, so it will likely be integrated in solid-filemanager in the future.
Open Solid Copy (currently available here. In the future likely on the solid-file-client website)
Copy from https://otman.inrupt.net/public/solid-plume-0.11/
To https://your-pod.example.org/public/plume/
Wait until it is finished…
Then you need to edit and rename config-example.txt. For instance with solid-filemanager:
Now plume should be installed on your pod and you can open plume in your browser (/public/plume/ without index.html at the end).
@happybeing If you want to be sure, that Solid Copy and the solid-plume-0.11 links are persistent, I’d suggest you to copy them to your pod. It could happen that they get deleted while I test stuff, or when I need more storage space…
@A_A install worked for me https://smag0.solid.community/public/plume/ 
But l’ve @happybeing, I’ve got an issue creating my first post :
I can type a word, then I want to type a space, and this appear and disappear, like if there was a .trim() function that cut the last space, and every time I type a space, the first word is concatenated to himself.
I type another space and the word is concatenated another time, until 6 times . See below
That’s very weird and I’ve not heard of it before. Can you file an issue and include info on browser and OS etc.
Also be great if you can you try after restarting the browser and in another browser to help gather info. Thanks for reporting!
I think this issue is very similar https://github.com/facebook/draft-js/issues/1077
the problem is with the SimpleMDE editor
https://embed.plnkr.co/rLyQa4/ --> pb with android with 3 different browser & 2 differents keyboards
known issue with simpleMDE https://github.com/sparksuite/simplemde-markdown-editor/issues?utf8=✓&q=is%3Aissue+is%3Aopen+android but not fixed, it seems that the better solution is to migrate to easyMDE https://github.com/sparksuite/simplemde-markdown-editor/issues?utf8=✓&q=is%3Aissue+is%3Aopen+android
tested on this page https://easymde.tk/ looks good for me
