Solid Plume - simple blog app

What point are you making here? What does commercial investment have to do with anything? I am speaking about?

Can you not simply look-up the links I shared to our repo and simply correct your inadvertent misrepresentation of the work on Plume.

If you are using Sergey’s work, and he is part of the OpenLink Software team. What’s confusing about the genesis of this work?

Your comments are inconsistent with the history of this work.

@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)! :slight_smile:

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.

3 Likes

Thank you two for illustrating my point so well :slight_smile: https://gitter.im/solid/chat?at=5cb0715db34ccd69e7a6cd3f

2 Likes

We’re 30 years into open source software, but effective collaboration at the small project level has barely progressed as far as I can tell.

1 Like

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?

Thanks, this is an important question.

In the server world I agree you would just provide a bridge, much like IPFS have done with Cloudflare, and this is a little simpler, but not that much really.

The downside is that you are now using servers again, with all their vulnerabilities and difficulties. I’d rather not go far into this in this topic (happy to do so elsewhere), but one of they key points about SAFE Network is that it eliminates servers as we know them, and this is one of the reasons it offers data security, privacy and above all greater ease of adoption and use: no server to buy / install / maintain, no pod service provider to trust / get taken over / switch business models, no bottlenecks vulnerable to overload / hacking / surveillance / DDoS etc.

From the user’s point of view not having a server involved is more secure, easier to adopt and to pay for (no subscription - you pay to store when you upload, no domain renewals, no need to ever switch service providers or migrate data).

Also URIs are permanent unless the owner chooses to redirect them, but even then the old versions remain accessible so as a culture we get a permanent web.

If you keep the traditional server in the loop, you lose those benefits. I don’t doubt people will also support that approach (servers as a gateway) but I see it as more of a problem than a solution because users may think they have the benefits of SAFE, when in fact very important features have been lost.

If you want to go deeper maybe we can spin off a new topic or chat elsewhere, and link to that here?

Plume Deployment Update

For folks who might want to deploy or pull my Plume code, please now pull the default branch gh-pages rather than solid-auth-client-smalinin. The default branch now has the working code (including changes suggested above by @A_A) and I’ll continue work on the latter.

So you can now just git clone https://github.com/theWebalyst/solid-plume to get Plume and follow deployment instructions here (now updated).

1 Like

Once again, we offer forks of NSS (see: https://github.com/OpenLinkSoftware/node-solid-server) that cover 4.x and 5.x. We also spend a lot of time ensuring these forks work with the interop tests laid out more than a year ago. Each includes Plume ready to go, since it is used in our second wave of QA testing while also providing a simply to use Solid App Showcase.

  1. https://solid.openlinksw.com:8444
  2. https://solid.openlinksw.com:8445

Demonstration of Plume bundles associated with both.

  1. https://kidehen3.solid.openlinksw.com:8444/common/plume/
  2. https://kidehen3.solid.openlinksw.com:8445/common/plume/

What would be useful is making Plume adhere to established “best practices” from the Blogosphere era e.g.,

  1. RSS and Atom Feeds
  2. Feed Discovery patterns via xhv:alternate relations in HTML metadata.

Those are the items we haven’t been able to address, due to our current bandwidth.

Why are those features important? They provide a nice bridge to a large community of folks that are trying to resurrect the Blogosphere – which offers a much more democratic and open approach to news and journalism as a whole.

Please try to make up - this is too important and I’m sure you are both on the same page

Nick

1 Like

Agreed. I’m still not clear on the status of the code in Sergey’s fork, why login doesn’t work and so on, so without any response to my questions I’ll be continuing my own fork (although slowly! also due to bandwidth :slight_smile: ). I’ll remain open to collaboration from anyone, and happy to issue PRs to any fork that wants my changes. For now though I’m doing other stuff.

@A_A do you (or anyone here) have any thoughts on better ways to deploy the Plume files? I was going to see if solid-filemanager can unzip files (as I see it can zip them) but haven’t had time to try it yet.

Better still would be a deploy to pod script but I don’t have time to work on that yet. I think that would be of general use and could be bundled with different apps.

Any other ideas spring to mind?

And to everyone: PRs on this and other issues very welcome. Plume is a great little starter app for newcomers, so I think even though it is old (pre LDflex code) it is worth getting it to a decent usable, easily deployed state.

Alternatively someone might like to rewrite it or make an equivalent simple blog app using the Inrupt SDK? That would be a nice project.

I’ll be happy to see any of these, and to help out where I can.

2 Likes

Its great what you’re doing with Plume. Recently I remembered https://mavo.io/ which extends html in a way like web components, but it has the advantage of having no dependencies, some nice demos at https://mavo.io/demos/ , and a way to extend it with backend plugins. It could also be used to make blogs. Ruben Verborgh wrote a Mavo backend for Solid a while ago. I dont know if that still works, but its at https://github.com/solid/mavo-solid . Currently there is a limitation that a backend can use only one resource specified in the html with the mv-storage attribute. If mavo-solid could be updated and/or Mavo itself could be modified to allow multiple and inherited mv-storage attributes, that would I think be a great project if someone is looking for one. I’m thinking about it and if it makes sense (and I can get up off the couch) I’d be happy to contribute to that.

1 Like

Something I am not sure about is, how to handle the .acl file. Because the solid-filemanager doesn’t display such files and therefore I’d suggest to either configure it before zipping and uploading or (my preferred solution) upload the zip and .acl file separately.

Apart from that I would suggest to zip it and let the user upload and extract it via the solid-filemanager (right click -> Extract here). This would also make it easy for the user to select the storage location.

For the future, I am planning to implement a file transfer between pods in the filemanager. So you could upload it to a public folder in your project pod and the user simply copies it to his/her own pod. And regarding the .acl files: I haven’t really looked into this yet, so maybe there is something I can do about them too (a permissions menu would be cool, but dunno if that is possible). But both of these are still only under consideration.

And I’ve also thought about creating a deploy to pod script but this could be inconvenient to use for non-programmers (and also coding language specific). Therefore I’d suggest to do this via any kind of web interface, which could have a nice user experience and is platform agnostic. I think it would be nearly sufficient to copy files from one pod to another for installing apps. But I agree that for programmers a script could be convenient. If it’s only uploading it should be easy to do though.

And if you want to start a longer discussion, we should probably move this to another thread

2 Likes

Here is our repo with the code properly merged. As for your “commercial investment” comment, is that necessary?

I’ve told you repeatedly that we couldn’t prioritize cleaning up the repo if nobody was interested in it. Now it appears folks are, so the repo has been cleaned up.

Repository Link: GitHub - OpenLinkSoftware/solid-plume: Plume, a Solid blog platform!

It wasn’t meant to offend. I was confused and speculating as to why you hadn’t responded to my question, and then posted that long post revealing that you had working code, yet still didn’t clarify the things I was asking about and accused me of misrepresenting the situation. I think we could both reflect on our communications.

I apologise for misunderstanding the situation and the offence I’ve caused by that remark.

I’ve told you repeatedly that we couldn’t prioritize cleaning up the repo if nobody was interested in it. Now it appears folks are, so the repo has been cleaned up

I don’t think this is accurate or helpful so will just thank you for cleaning up the repo, but as you know from the Solid chat I’d already resolved the issues with help from Ruben Verborgh today. So unless you repo has additional functionality now, my fork has already moved ahead of it (with unpushed maintenance, tidying and bugfixes).

I remain willing to look at how we can combine forces and maybe develop a reference repo, but I’m not seeing my offers to do that reciprocated so I’m going to assume we maintain different forks and can merge individual features ad hoc. That’s fine too.

I am though aware that I may be diverging from some of the intentions for the original code because I don’t know what they were!

1 Like
  • I think the .acl file should be deleted.
    It is inherited, and eventually modified using the rainbow pane of the plume folder. The actual way to import is extremely dangerous. Personally I locked the folder with a mistake. My bad

  • The distribution of the file without any .acl file can be made as a zip file imported with the AA solid-file manager :
    ** unzipped in place
    ** and edit the config with it

1 Like

I agree it is a problem now, but the solution is to prevent the owner a of from being able to lock themselves out - ie in the server implementation.

I’ve already removed the acl file from the folder to make this safer, and replaced it with a template. It doesn’t solve the problem entirely, but includes instructions and a warning in the file itself.

At the moment users can still mess things up by editing or creating.acl files - and I’ve also done this - so I think the server needs to provide safeguards, and a way to recover access by the pod owner.

FYI, @RubenVerborgh knows what we’ve been doing with Plume etc… Our goal was to progressively make all the apps built by Andrei work with the new Solid Authentication Layer.

Moving forward, are you going to address new features such as:

  1. RSS and Atom Feed Generation
  2. Use of POSH (Plain Old Semantic HTML) for Feed Discovery

Those are important features missing from Plume right now.

I think you should even remove the .acl template. There is no need of any

It is currently needed but I could probably remove that need in order to get rid of it. I’m not sure when I’ll be able to do that though as something has come up.