Post B2NfRl5oojV7F8LM5w by evan@cosocial.ca
(DIR) More posts by evan@cosocial.ca
(DIR) Post #B2NfRiiLf1XRrlLaEa by evan@cosocial.ca
2026-01-17T02:21:19Z
0 likes, 0 repeats
@julian @silverpill @slyborg I will fight pretty hard against breaking changes in ActivityPub. We have an active network with tens of millions of people and tens of thousands of servers. It's too late for breaking changes and it has been for a really long time. Expect changes like: describing required properties of activities better. How `replies` (and maybe `context`) work. References to OAuth, Webfinger and HTTP Signature.
(DIR) Post #B2NfRjX2cY5WOz44FU by evan@cosocial.ca
2026-01-17T02:23:30Z
0 likes, 0 repeats
@julian @silverpill @slyborg it's also worth noting that all discussions of the WG will be on a public mailing list. People can join the meetings, comment on drafts on GitHub. People interested in making more substantive contributions can become invited experts, even if they're not from a member organization.
(DIR) Post #B2NfRkFhwToidVxjs0 by evan@cosocial.ca
2026-01-17T02:25:56Z
0 likes, 0 repeats
@julian @silverpill @slyborg most importantly: no protocol is mandatory. No protocol revision is mandatory. If the work the WG does isn't useful, nobody has to implement it.
(DIR) Post #B2NfRkX4ttiBVO5bwe by evan@cosocial.ca
2026-01-17T02:28:37Z
0 likes, 0 repeats
@julian @silverpill @slyborg the issues I have marked for the next version are here. https://github.com/w3c/activitypub/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22Next%20version%22I know there are some on there that Silverpill won't like, such as supporting IRIs for object IDs. I think it's worth having that conversation.
(DIR) Post #B2NfRl5oojV7F8LM5w by evan@cosocial.ca
2026-01-17T02:41:05Z
0 likes, 0 repeats
@julian @silverpill @slyborg I wonder, though: what would be some changes that would worry you? I'm having a hard time imagining what they would be. The best I can come up with are features that are too complex for small development teams (e.g. oodles of mandatory APIs), or too resource intensive for small instances to support (e.g. required to handle terabytes of big data).
(DIR) Post #B2NfRteqyMHLo6nRoW by evan@cosocial.ca
2026-01-17T02:42:22Z
0 likes, 0 repeats
@julian @silverpill @slyborg The only other thing I can think of are forced anti-features, like mandatory advertising, mandatory algorithmic feeds, or forced participation in LLM training. Are there other things I'm missing?
(DIR) Post #B2NfRzbAswtwER7aue by evan@cosocial.ca
2026-01-17T04:05:54Z
0 likes, 0 repeats
@julian @silverpill for you two especially, I wonder if you think there could be Trojans inserted into the ActivityPub 1.1 spec -- something that seems innocuous on the surface, but would actually EEE the Fediverse? I just don't think the standard is complex enough that anyone could hide anti-features in it that you and I couldn't find. Maybe, I dunno.
(DIR) Post #B2NfS5G7q7d3mtJrw8 by evan@cosocial.ca
2026-01-17T04:06:55Z
0 likes, 0 repeats
@julian @silverpill I think a heaping dose of skepticism is healthy for standards efforts. I'm glad to know you're keeping your eyes open.
(DIR) Post #B2NimPWOVvQQHhJUGm by eyeinthesky@mastodon.social
2026-01-17T06:38:30Z
0 likes, 0 repeats
@evan @julian @silverpill @slyborg What about "breaking" bug fixes in the spec? Many parts of spec are used by ~0 people on ~0 servers so the impact is only positive to do those fixes. Required properties is an interesting topic. Adding a required property beyond `id` (conditionally), `type`, and `input`/`outbox` for actor types *would* be breaking and potentially have a large negative impact (unless they are only associated with optional new features).
(DIR) Post #B2NimR7eYsp5FXkkz2 by silverpill@mitra.social
2026-01-17T16:35:59.063009Z
0 likes, 0 repeats
@eyeinthesky One of such "bug fixes" has already been proposed:In section 4.1 "Actor objects", the definition of "inbox" uses the imprecise term "reference" and is different from the definition of "outbox", giving the false impression that the range of the "inbox" property is different than that of "outbox". A possible correction is to make the definition of inbox parallel with that of outbox: "An OrderedCollection comprised of all the messages received by the actor; see 5.2 Inbox."-- https://www.w3.org/wiki/ActivityPub_errataPreviously, inbox was a reference, but now an embedded inbox collection will be considered valid:{ "type": "Person", "inbox": { "type": "OrderedCollection", "items": [] }It's a breaking change. I don't actually mind the change itself, but the way it was made. When I pointed out that this change affects existing implementations and asked to amend the erratum, other participants literally started to gaslight me with "there is no change" and completely ignored my objections.@evan @julian @slyborg