- From: Evan Prodromou <evan@prodromou.name>
- Date: Mon, 2 Jun 2025 09:37:49 -0400
- To: Melvin Carvalho <melvincarvalho@gmail.com>
- Cc: "public-swicg@w3c.org" <public-swicg@w3c.org>
- Message-ID: <f7e9c94f-992b-4d6b-9e73-29e3edfe077b@prodromou.name>
Can we apply the erratum as written, and deal with "all" in a separate issue? And yes, please, open an issue on the ActivityPub issues repo, please! Evan On 2025-06-01 6:58 a.m., Melvin Carvalho wrote: > > > pá 30. 5. 2025 v 20:15 odesílatel Evan Prodromou <evan@prodromou.name> > napsal: > > Great question. > > The original text is: > > /A reference/to an [ActivityStreams] OrderedCollection > comprised of _all_ the messages received by the actor; see 5.2 > Inbox. > > Note the underlined all. What we're changing here is "/A > reference/to an [ActivityStreams] OrderedCollection" > to "An OrderedCollection", to be more parallel with the outbox > property. > > I do see your point; some implementations don't even make this > collection readable, so even though POSTing to the collection is > adding an activity to it (POST-to-create pattern), it doesn't > "stay there". > > It's a little orthogonal to this erratum, though. Would you mind > adding a new issue to the repo? > > > Thanks Evan, that makes sense. > > Just to add a bit of historical context, when I originally suggested > the "Semantic Inbox", the intention was quite similar to an email > inbox, only better, since it leveraged HTTP to support richer, > structured data messages. Semantic Inbox then evolved into what became > Solid's inbox pattern, and from there, it influenced the inbox concept > used today in ActivityPub. > > I'm genuinely delighted to see this idea getting traction and being > used so effectively! You're right that implementations vary, email > inboxes, for example, tend to be private by default in the email > world, and people often delete items or even strive for "inbox zero." > An inbox can be a temporary staging area rather than permanent storage > (think physical offices), and that's a perfectly valid use-case too. > > I completely agree we're looking at both errata and architecture > topics here, althought they're slightly intertwined. Perhaps it'd be > helpful if we could reflect briefly on how inboxes are practically > used across implementations today, and then use those insights to > inform our errata and clarify the definition? > > Happy to open an issue to dive deeper into this if that helps. > > > Evan > > On 2025-05-28 2:21 a.m., Melvin Carvalho wrote: >> >> >> pá 23. 5. 2025 v 18:33 odesílatel Evan Prodromou >> <evan@prodromou.name> napsal: >> >> Issue #289 of the ActivityPub GitHub repository notes the >> inexact and asymmetrical language used for defining the >> `inbox` and `outbox` collections: >> >> https://github.com/w3c/activitypub/issues/289 >> >> To resolve this, there is a proposed erratum for Section 4.1 >> to bring the definition of the `inbox` property closer to >> that of the `outbox` property: >> >> * In section 4.1 "Actor objects", the definition of "inbox" >> should read, "An OrderedCollection comprised of all the >> messages received by the actor; see 5.2 Inbox." >> >> We usually handle approval of errata in our synchronous >> meetings, which takes a lot of time and focus away from other >> topics that require more immediate presence and conversation. >> In speaking with the chairs and others in the issue triage >> meeting, we think that handling this task through the CFC >> decision-making process will be more efficient. >> >> So, I am seeking consensus to add this erratum to our errata >> page for ActivityPub. Please reply either to the GitHub issue >> or here on the mailing within 14 days of this message. >> >> >> Thanks Evan, small point to consider: does “all” messages mean >> every received message should be archived in the inbox? I’m not >> sure all implementations do that. >> >> Evan >> >>
Received on Monday, 2 June 2025 13:37:53 UTC