#ActivityPub is getting its first formal update path since 2018.
-
I did not think about this aspect (why would I, I have no idea who is a paid member of the W3C <img class="not-responsive emoji" src="https://activitypub.space/assets/plugins/nodebb-plugin-emoji/emoji/android/1f606.png?v=03884acde30" title="
" />), but this is a potentially concerning data point.> There are only two organisations that are active in the fediverse that are a paid member of the W3C: Meta and the Social Web Foundation. With the Social Web Foundation also receiving funding from Meta, the company that built Threads now has more institutional standing in ActivityPub governance than any of the organisations actually building open fediverse software. Mastodon gGmbH, Framasoft, and others are not W3C members and cannot participate in the Working Group unless they are invited.
>
> This is by all accounts an extremely funny outcome for a network that aims to be independent of Big Techβs power.β @fediversereport@mastodon.social
How this WG shapes up in the coming weeks will be interesting to watch
Thank you for sharing this update.@julian @fediversereport AP is an ugly duckling.
Maybe it shouldn't be a Web standard, but sit apart from (and inter-operate with) it instead. Maybe the right org is the IETF...
-
@fediversereport If they are smart they will fix a raft of fundamental UX pitfalls in current ActivityPub by defining a protocol handler for it.
Email needed its protocol handler spec while it was getting established β and arguably still does β and I do think this is one of the ways in which ActivityPub is "like email".
@tasket@infosec.exchange an official protocol handler would help a lot. Today there is the option of introducing a web protocol handler but the UX for it is pretty dogshit (Piefed recently implemented it, and the number of dialogues was too damn high!)
That said I don't know if PWAs can register against non-web protocol handlers. That would be useful for sites like NodeBB.
-
Here's my question though... The w3c rules stipulate that any changes must be accompanied by two implementations.
That's a pretty strong check against unilateral decision-making and introduction of breaking changes from the WG.
@julian There are several dozens of actively maintained ActivityPub implementations, I think it is not difficult to find two implementers among them, especially if they will be paid to implement a proposed change / extension (as we have seen with the E2EE proposal).
@slyborg @evan @connected-places @fediversereport @ArneBab @alexchapman
-
@tasket@infosec.exchange an official protocol handler would help a lot. Today there is the option of introducing a web protocol handler but the UX for it is pretty dogshit (Piefed recently implemented it, and the number of dialogues was too damn high!)
That said I don't know if PWAs can register against non-web protocol handlers. That would be useful for sites like NodeBB.
@julian IMO there's no reason why a web browser should understand where to open fedi links, without having any other type of app properly address those links as well.
What if someone in an instant messenger or email app sends you a link to fedi content?
Defining it at the system level (again, as is done with email) removes critical uncertainties.
Fedi has other big UX issues as well. Celebrities don't like it here because the TL mechanics make them unintentionally annoying... users follow then later mute them because their posts are popular for a while and we have to see them each and every time they're boosted (or manually silence those posts). Allowing the selection of some transparent algorithms could fix this.
-
@julian There are several dozens of actively maintained ActivityPub implementations, I think it is not difficult to find two implementers among them, especially if they will be paid to implement a proposed change / extension (as we have seen with the E2EE proposal).
@slyborg @evan @connected-places @fediversereport @ArneBab @alexchapman
@silverpill In a hilarious twist of fate, this gives (streams) and Forte an unfair advantage. They're nearly identical, they have the same maintainer, but they're two separate implementations, also seeing as Forte uses ActivityPub for nomadic identity, and (streams) doesn't and still uses its own Nomad protocol for it.
Since Mitra appears to implement (streams)/Forte features one by one and cast them into FEPs, that's three implementations already. Two if nomadic identity via ActivityPub is involved. And if Hubzilla happens to have it, too, we've got up to four implementations.
Yes, ActivityPub is only an optional add-on on Hubzilla and (streams), but an implementation is an implementation. And whatever they do on Nomad that federates has to get out through ActivityPub one way or another.
It'd be even more hilariously skewed, hadn't Mike discontinued the five apps between Hubzilla and (streams) on New Year's Eve 2022.
CC: @slyborg @Evan Prodromou @Connected Places @ArneBab @Alex Chapman
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #ActivityPub #Hubzilla #Streams #(streams) #Forte #Mitra -
Here's my question though... The w3c rules stipulate that any changes must be accompanied by two implementations.
That's a pretty strong check against unilateral decision-making and introduction of breaking changes from the WG.
@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.
-
@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.
@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.
-
@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.
@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.
-
@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.
@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%22
I 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.
-
@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%22
I 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.
@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).
-
@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).
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?
-
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?
@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.
-
@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.
@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.
-
@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.
@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).
-
The only way compromise happens is if there are other players of similar size in the committee to counterbalance a large player. If this is Meta and a bunch of nonprofits, Meta either dictates the standard or forks it and effectively replaces it. (2/2)
@slyborg I think this is a great point.
-
@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).
The best I can come up with are features that are too complex for small development teams
This is probably the biggest risk.
Another risk is changes that prevent the development of important features in the future.
-
@silverpill In a hilarious twist of fate, this gives (streams) and Forte an unfair advantage. They're nearly identical, they have the same maintainer, but they're two separate implementations, also seeing as Forte uses ActivityPub for nomadic identity, and (streams) doesn't and still uses its own Nomad protocol for it.
Since Mitra appears to implement (streams)/Forte features one by one and cast them into FEPs, that's three implementations already. Two if nomadic identity via ActivityPub is involved. And if Hubzilla happens to have it, too, we've got up to four implementations.
Yes, ActivityPub is only an optional add-on on Hubzilla and (streams), but an implementation is an implementation. And whatever they do on Nomad that federates has to get out through ActivityPub one way or another.
It'd be even more hilariously skewed, hadn't Mike discontinued the five apps between Hubzilla and (streams) on New Year's Eve 2022.
CC: @slyborg @Evan Prodromou @Connected Places @ArneBab @Alex Chapman
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #ActivityPub #Hubzilla #Streams #(streams) #Forte #Mitra@jupiter_rowland The two-implementation requirement sounds totally inadequate to me. Does it really work like that?
I think nothing new should ever be added to the core spec unless it is supported by 51% of implementers.
-
@jupiter_rowland The two-implementation requirement sounds totally inadequate to me. Does it really work like that?
I think nothing new should ever be added to the core spec unless it is supported by 51% of implementers.
@silverpill 'Implemented' is not boolean, some FEPs have partial implementations, implementations of a prior draft or implementations that do the opposite of a MUST
-
@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).
@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_errata
Previously,
inboxwas a reference, but now an embeddedinboxcollection 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.
-
@silverpill 'Implemented' is not boolean, some FEPs have partial implementations, implementations of a prior draft or implementations that do the opposite of a MUST
@dimkr I mean implementers of ActivityPub specification. I think if a feature doesn't rise to the level of "most projects should support it", it shouldn't be included in the specification.
FEPs are a different story, In many cases 2 independent implementations of a FEP is enough.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better π
Register Login