Decide on a protocol #1

lizzie commented 2025年08月02日 14:07:30 +02:00

Thought it might be helpful organizationally to take some of the discussion on other platforms and put it here.

Some options:

1. ActivityPub
2. ATProto
3. WebSub, RSS, WebMentions, etc.
4. Some sort of webhook

ActivityPub

Pros

• Theoretically designed specifically for stuff like what we're doing.
• Decentralized

Cons

• Massive headache to implement.
• Requires way more infrastructure than our use case really needs.

ATProto

(mostly summarizing from conversations in discord here)

Pros

• Relatively lightweight, wouldn't be as involved to implement as ActivityPub

Cons

• !!! Requires at least one platform to handle all of the traffic of the entire network

• Doesn't decentralize nearly as well as we'd like

IndieWeb Stuff:

Pros

• A lot lighter than ActivityPub
• Decentralizes much better than ATProto

Cons

• We have to figure out exactly how we're implementing this, like with microformats (h-product?) (webmentions?) (RSS or maybe a json feed?)
• Would require hub infrastructure which, while likely simpler than ActivityPub, isn't quite as simple as just an API endpoint or a webhook.

We could also decide to implement something like a simple webhook for this stuff if we're not happy with the other options for whatever reason. It would almost definitely be lighter than WebSub, but it's also not a standard and there's at least some value in that.

Feel free to let me know if I've got anything wrong, I'm not super familiar with any of the standards listed. I just thought it would be valuable to have a centralized place for discussion of this stuff in the repo!

Thought it might be helpful organizationally to take some of the discussion on other platforms and put it here. Some options: 1. ActivityPub 2. ATProto 3. WebSub, RSS, WebMentions, etc. 4. Some sort of webhook ## ActivityPub ### Pros - Theoretically designed specifically for stuff like what we're doing. - Decentralized ### Cons - Massive headache to implement. - Requires way more infrastructure than our use case really needs. ## ATProto (mostly summarizing from conversations in discord here) ### Pros - Relatively lightweight, wouldn't be as involved to implement as ActivityPub ### Cons - !!! Requires at least one platform to handle all of the traffic of the entire network - Doesn't decentralize nearly as well as we'd like ## IndieWeb Stuff: ### Pros - A lot lighter than ActivityPub - Decentralizes much better than ATProto ### Cons - We have to figure out exactly how we're implementing this, like with microformats (h-product?) (webmentions?) (RSS or maybe a json feed?) - Would require hub infrastructure which, while likely simpler than ActivityPub, isn't quite as simple as just an API endpoint or a webhook. We could also decide to implement something like a simple webhook for this stuff if we're not happy with the other options for whatever reason. It would almost definitely be lighter than WebSub, but it's also not a standard and there's at least some value in that. Feel free to let me know if I've got anything wrong, I'm not super familiar with any of the standards listed. I just thought it would be valuable to have a centralized place for discussion of this stuff in the repo!

chaoscat commented 2025年08月02日 14:31:46 +02:00

I favor #3. I think webmention can easily hook into ActivityPub so anyone who wants to extend it in that direction could do so (I could be wrong tho).

I favor #3. I _think_ webmention can easily hook into ActivityPub so anyone who wants to extend it in that direction could do so (I could be wrong tho).

lizzie commented 2025年08月02日 23:49:29 +02:00

yeah, it's fairly simple to do that. see: https://indieweb.org/ActivityPub#ActivityPub_Notifications_to_Webmention

yeah, it's fairly simple to do that. see: <https://indieweb.org/ActivityPub#ActivityPub_Notifications_to_Webmention>

zkat commented 2025年08月03日 07:09:58 +02:00

I looked into it and asked around and it seems like a combination of just plain h-feed, h-product, etc plus a very very simple webhook would be more than enough for our use case. We don’t even really need RSS/Atom.

Webmentions, it turns out, are more for comments/replies/reviews/etc. so we can still use them for those things but it doesn’t seem like those are what we want for notifying bazaars.

There is also something called WebSub but it’s kinda spottily supported and probably overkill for our foreseeable needs. See this post and its containing thread: https://toot.cat/@jamey/114958198078290438

The final piece of the puzzle is the webring protocol for what information bazaars collect about each other and how they share information about supported tags (possibly even cryptographically hashed sensitive tags?) and keep those in sync, which I think we can use the same general strategy for as above

I looked into it and asked around and it seems like a combination of just plain `h-feed`, `h-product`, etc plus a very very simple webhook would be more than enough for our use case. We don’t even really need RSS/Atom. Webmentions, it turns out, are more for comments/replies/reviews/etc. so we can still use them for those things but it doesn’t seem like those are what we want for notifying bazaars. There is also something called WebSub but it’s kinda spottily supported and probably overkill for our foreseeable needs. See this post and its containing thread: https://toot.cat/@jamey/114958198078290438 The final piece of the puzzle is the webring protocol for what information bazaars collect about each other and how they share information about supported tags (possibly even cryptographically hashed sensitive tags?) and keep those in sync, which I think we can use the same general strategy for as above

lizzie commented 2025年08月03日 12:59:18 +02:00

@zkat wrote in #1 (comment):

There is also something called WebSub but it’s kinda spottily supported and probably overkill for our foreseeable needs. See this post and its containing thread: https://toot.cat/@jamey/114958198078290438

this thread was pretty helpful!

i was curious and looked into websub a bit more. the w3c docs are kind of difficult to parse (as w3c docs tend to be), so i'm not sure how well i understood them but

they operate on a publisher / subscriber / hub setup, where in our case we'd likely have the bazaars act as both hubs and subscribers (as Jamey mentioned in that thread). i think on some level that kind of defeats the purpose of the distinction, but, nevertheless.

we could also have like, a centralized hub in practice (say, webhub.conjured.ink) which then pushes to bazaars. i think this would defeat the point of a lot of what we're doing and probably be Bad, but, we could do it.

anyway. it also supports a single publisher publishing to multiple hubs, so no problems there.

it supports periodic checks for subscriptions being maintained and also unsubscription, and has some security / auth stuff. im not at all educated on cryptography but it supports sha1, sha256, sha384, and sha512. kind of wild seeing sha1 supported for this at all lol.

lastly, checked out some implementations of hubs (https://github.com/clone1018/WebSubHub is an elixir implementation). i did a cursory glance over the code and it doesn't seem it would be all that bad for us to implement a hub built into our bazaar software.

... anyway. i did all that to say that, it looks like the use case for it doesn't map perfectly onto what we're doing but we could make it work for sure. it seems a bit overcomplicated and it has questionable value for us to implement a protocol that's barely used and fairly unknown. atp i'm not sure it would be significantly different from just writing our own, simpler thing that fits us better. we don't get much value out of standards if other people don't even use them anyway. so, +1 to just a simple webhook w/ h-feed and h-product.

@zkat wrote in https://codeberg.org/conjured/cauldron/issues/1#issuecomment-6109096: > There is also something called WebSub but it’s kinda spottily supported and probably overkill for our foreseeable needs. See this post and its containing thread: https://toot.cat/@jamey/114958198078290438 this thread was pretty helpful! i was curious and looked into websub a bit more. the [w3c docs](https://www.w3.org/TR/websub/) are kind of difficult to parse (as w3c docs tend to be), so i'm not sure how well i understood them but they operate on a publisher / subscriber / hub setup, where in our case we'd likely have the bazaars act as both hubs and subscribers (as Jamey mentioned in that thread). i think on some level that kind of defeats the purpose of the distinction, but, nevertheless. we could also have like, a centralized hub in practice (say, webhub.conjured.ink) which then pushes to bazaars. i think this would defeat the point of a lot of what we're doing and probably be Bad, but, we could do it. anyway. it also supports a single publisher publishing to multiple hubs, so no problems there. it supports periodic checks for subscriptions being maintained and also unsubscription, and has some security / auth stuff. im not at all educated on cryptography but it supports sha1, sha256, sha384, and sha512. kind of wild seeing sha1 supported for this at all lol. lastly, checked out some implementations of hubs (<https://github.com/clone1018/WebSubHub> is an elixir implementation). i did a cursory glance over the code and it doesn't seem it would be all that bad for us to implement a hub built into our bazaar software. ... anyway. i did all that to say that, it looks like the use case for it doesn't map perfectly onto what we're doing but we could make it work for sure. it seems a bit overcomplicated and it has questionable value for us to implement a protocol that's barely used and fairly unknown. atp i'm not sure it would be significantly different from just writing our own, simpler thing that fits us better. we don't get much value out of standards if other people don't even use them anyway. so, +1 to just a simple webhook w/ `h-feed` and `h-product`.

lizzie commented 2025年08月03日 13:18:15 +02:00

@zkat wrote in #1 (comment):

The final piece of the puzzle is the webring protocol for what information bazaars collect about each other and how they share information about supported tags (possibly even cryptographically hashed sensitive tags?) and keep those in sync, which I think we can use the same general strategy for as above

i don't see why it would have to be significantly different than the general strategy, yeah. some of these details are stuff we'll have to work out with creatives though re: safety, robustness against harassment.

@zkat wrote in https://codeberg.org/conjured/cauldron/issues/1#issuecomment-6109096: > The final piece of the puzzle is the webring protocol for what information bazaars collect about each other and how they share information about supported tags (possibly even cryptographically hashed sensitive tags?) and keep those in sync, which I think we can use the same general strategy for as above i don't see why it would have to be significantly different than the general strategy, yeah. some of these details are stuff we'll have to work out with creatives though re: safety, robustness against harassment.