V3: A modular version based on protocols/requirements?

[nigini]

Some thoughts I had about the multiple requirements that MicroBlog.pub has been juggling with: micropub server, micropub client, activitypub server, activitypub client, blogging platform, blogging site...

I have been wondering about a v3 that has all of the above (and maybe more) as modules, and you can pick whatever serves you best. Two major things I thought about:

1. Why don't we use an ActivityPub server instead of implementing something new? (I have not found though, a minimalist implementation on Python. If that is the case, we could break this out as a separate component.)

2. The interesting thing about the MicroPub ecosystem, is the ability to use whatever client you prefer. In this way, we could actually separate the current admin pages as a minimalist implementation of that and give users the chance to use/improve the clients as they may.

Thoughts?

[1dom]

I've been tinkering with microblog.pub for a fair few months in private. I noticed tsileo seems to have disappeared, and I saw this project, along with the discussion. I wanted to throw in my opinion on what made microblog.pub unique, and where I think it should go.

microblog.pub to me looked like an implementation of a lot of the tech and philosophies associated with indieweb, open source, and a sustainable, individual and wholesome internet. The specific appeal for me was that it at least partially implements micropub, activity pub, as well as webmentions and indieauth (although I don't really use any of them yet).

Some other things I liked which seemed relatively unique to microblog.pub:

• not many dependencies
• not many different technologies outside of Python, HTML and CSS
• a focus on open, sustainable interoperability and portability at all levels (e.g. all data in data folder, support for different federation and communication protocols etc.)

I've spent some time in the tsileo codebase, and I do love the project, but some parts do seem a victim of awkward iterating and learning, and other parts could do with a rewrite.

A few more observations:

• It felt like at some point, the project only wanted to be a UI for the reader/visitor, not the author/admin. I think it would be better to focus on completing the micropub implementation and any other backend API protocols so people can use their UI or scripts of choice for administering content.
• Javascript looks to have been purposefully avoided, I think this is special and should stay the default focus of this project. With all the open protocols correctly implemented on the backend, there's probably more than enough to create some shiny async JS frontends and admin UIs in a different project.
• I think it's a good idea to reassess all the protocols being implemented now, see if any new ones are also appropriate (AT protocol?) as well as all the different content types (articles, blogs, notes, custom? shorts?). A modular plugin system designed with those protocols and maybe content types as default plugins might be a good foundation for a rewrite.

Ultimately, microblog.pub lets people host their own website. However, there are so many technically easier and better ways to implement that which the original creator chose not to accept. I'd guess microblog.pub exists because its focus was on socially hosting your own stuff in a particular way, a simpler, open and more individual way. The trade-offs for that are the implementation is slightly harder, slower and not as shiny - I think that's one of the most endearing features and should be preserved.

With that in mind, regarding your questions, you should take a look at the micropub implementation, it already does a bunch of stuff you're asking about: https://github.com/microblog-pub/microblog.pub/blob/main/app/micropub.py. I've played around with it and been able to successfully auth and post stuff. It's usable but incomplete.

Adding basic update support wasn't too hard (see https://github.com/microblog-pub/microblog.pub/blob/main/app/micropub.py#L109 and https://github.com/microblog-pub/microblog.pub/blob/main/app/boxes.py#L826, just need hooking up.) Although beyond basic support - such as updating tags etc - should probably be done by merging that send_update function with the send_create function further up. As to "why don't we use an existing server" - I think it's entirely up to the project direction to decide: but I don't feel using an external existing implementation is in the spirit of the original project personally.

[nigini]

Hey, @1dom. Thanks for taking the time to write such a thorough response. I am really glad that one more person is interested in keeping this project alive. I believe we are pretty much aligned on the architectural revamp, mainly separating things into plugins and the server from the client.

I think you are right about the code pointers. I have been studying the code as well, but haven't seen those. Should we open an issue for implementing the update function? Would you like to have a first shot on that?

Also, where is your instance living? Did you see that we have integrated a bunch of library updates from @JD557 ? Do you have improvements that we should integrate?

Regards.

[1dom]

Most of my work has just been playing on local branches, I've not actually got it running or shared anywhere. I just forked this repo and picked the relevant commit for this though: #8. That PR is more in the direction of hacking the current code, rather than rewriting it to not have to operate so hackily.