Bonfire shared inbox usage
Technical Discussion
5
Posts
3
Posters
0
Views
-
Hi @mayel@sunbeam.city, does Bonfire utilise the
sharedInboxvalue?I noticed this come through my nginx logs today:
128.140.127.206 - - [21/Jan/2026:19:58:04 +0000] "POST /uid/1/inbox HTTP/1.1" 500 128 "-" "https://btfree.social - Bonfire ActivityPub federation" "-"/uid/1/inboxis an endpoint specified in my user'sinbox, but that actor also sends"endpoints":{"sharedInbox":"https://activitypub.space/inbox"}, so wanted to double-check that Bonfire uses it. It should, it helps reduce the number of requests to send if multiple users belong to the same server :smile: -
@julian@activitypub.space Hi yes we send to sharedInbox when there's more than one recipient on that instance, otherwise direct to to the user's inbox.
-
@julian@activitypub.space Hi yes we send to sharedInbox when there's more than one recipient on that instance, otherwise direct to to the user's inbox.
@mayel@bonfire.cafe oh that is an interesting choice. I suppose that makes sense, I never really thought about it. NodeBB just sends to shared inbox if available.
-
@julian @mayel subtle difference: sharedInbox is not delivering to the individual inboxes, and it is not strictly delivering to the addressed actors either. what it *actually* means is "make the shared inbox decide who gets it, using the addressing as a *hint*". in theory, the shared inbox is supposed to distribute the activity to the appropriate inboxes internally. this, of course, leads to Problems when the shared inbox doesn't understand a specific recipient (like with private collections)
-
@julian @mayel subtle difference: sharedInbox is not delivering to the individual inboxes, and it is not strictly delivering to the addressed actors either. what it *actually* means is "make the shared inbox decide who gets it, using the addressing as a *hint*". in theory, the shared inbox is supposed to distribute the activity to the appropriate inboxes internally. this, of course, leads to Problems when the shared inbox doesn't understand a specific recipient (like with private collections)
@trwnh@mastodon.social that sounds like a them problem not a my problem š
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@trwnh@mastodon.social that sounds like a them problem not a my problem š
-
@trwnh@mastodon.social oooh that's interesting. I actually commented on the former.
But I am realizing now that NodeBB actually explicitly addresses quite a few people because we try to keep everybody in the loop.
Responding to a topic with hundreds of posts could mean a Note object with hundreds of individual users addressed in cc.
Perhaps it's wiser to not assume "addressed? generate notification.", and instead have configurable notifications based on thread/context participation.
-
@julian @mayel subtle difference: sharedInbox is not delivering to the individual inboxes, and it is not strictly delivering to the addressed actors either. what it *actually* means is "make the shared inbox decide who gets it, using the addressing as a *hint*". in theory, the shared inbox is supposed to distribute the activity to the appropriate inboxes internally. this, of course, leads to Problems when the shared inbox doesn't understand a specific recipient (like with private collections)
-
@julian thanks, i hate it
i mean, i get it... but i hate it xD
i would rather mastodon fixed this in mastodon, but i wouldn't blame you if you did. mainly, mastodon should use to/cc/audience when composing a post, not tag.
we have https://github.com/mastodon/mastodon/issues/32242 which is the inverse (receiving, not posting). i just filed https://github.com/mastodon/mastodon/issues/37568 for the other direction (posting, not receiving)
-
@mayel@bonfire.cafe oh that is an interesting choice. I suppose that makes sense, I never really thought about it. NodeBB just sends to shared inbox if available.
-
@julian@activitypub.space Hi yes we send to sharedInbox when there's more than one recipient on that instance, otherwise direct to to the user's inbox.
-
Hi @mayel@sunbeam.city, does Bonfire utilise the sharedInbox value?
I noticed this come through my nginx logs today:
128.140.127.206 - - [21/Jan/2026:19:58:04 +0000] "POST /uid/1/inbox HTTP/1.1" 500 128 "-" "https://btfree.social - Bonfire ActivityPub federation" "-"
/uid/1/inbox is an endpoint specified in my user's inbox, but that actor also sends "endpoints":{"sharedInbox":"https://activitypub.space/inbox"}, so wanted to double-check that Bonfire uses it. It should, it helps reduce the number of requests to send if multiple users belong to the same server :smile:
-
@julian (I replied to this from Hubzilla, but it doesn't seem to have showed up, so reposting from Mastodon... sorry for the duplicate)
Yes, it does.
I think FEP-171b is the relevant spec; Mike Macgirvin's description of Conversation Containers might be relevant too.
It's running Hubzilla, which is already listed as an implementer of FEP-f228.
