Bonfire shared inbox usage
Technical Discussion
5
Posts
3
Posters
20
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
-
-
@reiver Did you and I discuss queryfy a while ago, or was it one of my other projects?
Just wondering whether I owe you a heads up since queryfy has been bumped up to v0.3.0
-
With ActivityPub / ActivityStreams...
To me, it feels like there should have been something that is a common parent of both 'Object' and 'Link'.
That just had the "name", "nameMap", and "preview" fields (along with "id" and "type, of course) — since that is what 'Object' and 'Link' share in common.
I'll just call this common parent: 'Entity'.
...
It could have even been an opportunity to talk about how to handle unknown types.
-
@soapdog@toot.cafe hmm... just thinking aloud here.
You posit in another post that the network effects inflate exponentially:
> Push models are resource hogs that approach exponential growth in a large network like the fediverse
That's not true. If you post a message then it sends a copy to each follower. That's linear growth. If you collapse recipients via shared inboxes you can reduce that further.
If you're referring to the torrent of requests that happen if your post is shared (the "thundering herd" problem) then that's actually a PULL happening from those requesting instances!
Secondly, in a pull model of AP, you would need to continually poll servers of all your followers so as to approach a real-time effect. You'd be polling servers over and over again, and many of them would have nothing new, with so much wasted traffic.
If your expectations include semi real-time updates, the push model is much more performant, in my humble opinion.
-
@evan @mariusor @silverpill i think we probably need to revisit the user story of creating multiple objects at once, or more accurately, the user story of minting and binding multiple identifiers at once.
-
@evan my suggestion: https://github.com/w3c/activitypub/issues/533
-
@evan @mariusor @silverpill re: ids though the RDF ecosystem (and jsonld) doesn't use "null", it uses blank node identifiers (those prefixed with _: are special cased by the prefix expansion algorithm). this can allow for "transient" activities or "anonymous" objects (and the graph data model auto assigns _:b1, _:b2 and so on when "id" is missing; the canonicalization algorithm assigns _:c14n0 and _:c14n1 and so on)
this is maybe not the best way to create replies collections though...
-
@evan @mariusor @silverpill although note that i think nightpool is of the opinion that POSTing a non-activity to the outbox is an at-risk behavior and should be deprecated, because the "implicit Create" behavior has to somehow know whether or not the body of the POST is an Activity or not, and we never actually define how to know this, so it is too likely that the server will accidentally wrap activities in a Create if some inference fails.
