Refactoring and modularizing the protocols out of the App/blog repository (v3?)

[nigini]

One of the things I am most interested in (and that brought me to uBlog.pub) is the implementation of open web protocols. (BTW, I am not alone. Check #14.)

For instance, I would love to contribute to the implementation of an ActivityPub Python library. It only makes sense to me to do so as an effort related to our ORG (which I am starting to think we should change the name to something broader if you agree with my points here.) In my view, it would make a lot of sense to either extract the ActivityPub code as a new repo and build it as a library or start from an existing library (see this - especially, look at their "app/blog" page 😬).

The same rationale would obviously apply to WebMentions and any other protocol we want to support. What do you think?

[1dom]

I agree generally. I read a few of your posts, and some thoughts aloud:

I feel that the current implementation and architecture is very very heavily geared towards activitypub: inbox, outbox and processing of items are essentially the source of truth and are at the core of the current microblog.pub implementation. Everything else hangs off that back of or is triggered by that.

I was aware of bridgy, but never really poked around to get to granary. I don't fully understand granary yet, but it looks like it basically uses AS1 (basically activitypuyb) as a common language to convert between all the other popular social protocol languages.

I don't like reinventing the wheel, but I feel like what I want microblog.pub to be - in theory - is a really small selfhosted microblog site like it is now, but with granary attached to support to include relative things from other networks in the feed, and some outgoing equivalent to send/post/share/syndicate to other networks.

An approach to get to that place would be to break it into 3 parts:

1. stripping back to activitypub core (and make everything nicer, consistent, well tested, slightly more modern, remove everything that is better added back in later steps as modules etc.)
2. integrate granary somehow to have content read from other protocols and sources in the main stream
3. something to ensure stuff posted on microblog gets also sent/posted/shared/syndicated to all the other protocols/locations configured.

Not sure if the dsblank/activitypub came before or after microblog.pub. I can see dsblank has some of the first PRs on original master branch of tsileo/microblog.pub though. The main difference looks to be dsblank was more focused on being an activitypub only type thing.

[nigini]

Great points, especially the idea 2... I haven't looked throughly into Granary either, but this thing is translating in production, so I imagine it does a pretty good job. (Plus, I have been in recent group conversations with the author, and he seems to be really competent in the technical understanding of this bridging thing.)

I have, though, this gut feeling that the ActivityPub shouldn't be the core of the blog. The blog should be a very lightweight way to store and serve posts (maybe HTML one?); the "how to serve" would come with add-ons. If anything, to be true to its name, the MBP "app" as a micropub service, would make more sense if focused on the Indie Specs, right?

Again, at the same time I am interested in the blog part as a user; I am also very interested in all the open standards that are out there. As a user, I would love to have more control over how to share my content... As a dev, I would rather have components that I could reuse than all glued together in this one app. Does this make sense?

[1dom]

Hehehe, I was kind of thinking similar around activitypub as a core: I had intrusive thoughts to create our own simplified common structure or format, and then translate to/from all the others as needed. I find that structure of program really satisfying to think up and create from a nerdy perspective.

But thinking pragmatically, the outcome would essentially be granary, but with our own format instead of activitypub at the start, which feels like reinventing the wheel if granary exists.

Regarding indie spec, a bunch of those are already implemented. E.g. #19 is adding the initial update part of the micropub spec. h-card and h-entry is already implemented on the frontend too, and are referenced in the micropub spec too I think?

I agree regarding selection of standards available to user, implemented as modules by/for devs. How granular do you see the control of protocols? I can see a couple of extremes:

1. each new/edit post page has an "advanced" dropdown for the post, where you can then tick which protocols it's published over.
2. config.toml has a "protocols" parameter, which accepts a list of protocols/modules what all content is shared through by default.

I guess 2 is an MVP of 1.

Where's the best place to create a table of the protocols we're interested in? Table probably needs to capture the protocol name, the protocol category (e.g. is it a frontend protocols for structuring stuff in HTML, is it a backed protocol for sharing posts between servers, is a storage format type protocol.), current implementation status in microblog.pub, and a link to the official spec/standard for the protocol.

Not sure a discussion thread is the best place for such a table to live (although it could be formed here). Maybe a wiki or README.md?

[snarfed]

Hi all! Exciting that you're considering granary! I'm happy to answer any questions and help any way I can.

Your understanding of granary here, and how you could use it, makes sense. Granary does indeed use ActivityStreams 1 as its base format. Generally, to translate from format X to format Y, granary converts X to AS1, and then from AS1 to Y. This has tradeoffs, but it's worked well enough for us for a long time.

One minor note though: ActivityStreams is not ActivityPub. ActivityStreams is a data model and format, ActivityPub is a protocol. Granary understands both AS1 and AS2, but it doesn't do ActivityPub itself at all. It does implement a few other closed social network APIs though, as well as a couple open protocols, notably webmentions and Nostr (beta quality).

Otherwise, one thing I'm doing right now to improve usability is standardize the names of the core translation functions in all of the different modules. Right now there are a lot of different names, but soon they'll all be to_as1 and from_as1. Minor, but ergonomics count.

Lmk if I can help otherwise!

[snarfed]

Oh, also, granary hopefully shouldn't affect your own storage format. You should be able to store data in whatever format you want. HTML with microformats2, JSON Feed, AS2 JSON, even your own custom thing. As long as you can get it to a format that granary supports, you can then use granary to convert to any other format you need.