Recently there has been a lot of discourse about ActivityPub and AT Protocol which has been quite dividing and heated.
-
@mastodonmigration @breathOfLife @thisismissem @ikuturso @stefan That's because it's not true, it's completely normal to not know things that aren't real
@mastodonmigration @breathOfLife @thisismissem @ikuturso @stefan The relay (formerly "BGS") code has been open source since at least April 2023: https://bsky.app/profile/dholms.xyz/post/3jt33v44njk26
-
@stefan @fontenot @mastodonmigration I'm certain in time this graph will change, just as that of ActivityPub adoption and distribution has changed over the years.
AP has a 5 year head start at least here compared to AT Protocol, and I think the efforts ongoing at promising.
@thisismissem @stefan @fontenot
Hope you are right. And hope the community puts pressure on Bluesky PBC to help facilitate this shift.
-
@mastodonmigration @breathOfLife @thisismissem @ikuturso @stefan The relay (formerly "BGS") code has been open source since at least April 2023: https://bsky.app/profile/dholms.xyz/post/3jt33v44njk26
@mackuba @breathOfLife @thisismissem @ikuturso @stefan
No knowledge of any of this. Kuba has been a good source of information on all things Bluesky to us over here in the Fediverse.
-
@mastodonmigration @breathOfLife @thisismissem @ikuturso @stefan The relay (formerly "BGS") code has been open source since at least April 2023: https://bsky.app/profile/dholms.xyz/post/3jt33v44njk26
@mackuba @mastodonmigration @thisismissem @ikuturso @stefan
huh
then i guess the hoo-hah about atproto not being decentralized came simply from bluesky being a for-profit company.
which, fair enough, profit DOES incentivize enshittification and lock-in, and activitypub is mostly built as a service anyway in reaction to that.
suffice to say, there's always been a general vibe here that atproto was just a bluesky thing.
it took community effort to give atproto legs.
-
@mackuba @mastodonmigration @thisismissem @ikuturso @stefan
huh
then i guess the hoo-hah about atproto not being decentralized came simply from bluesky being a for-profit company.
which, fair enough, profit DOES incentivize enshittification and lock-in, and activitypub is mostly built as a service anyway in reaction to that.
suffice to say, there's always been a general vibe here that atproto was just a bluesky thing.
it took community effort to give atproto legs.
@breathOfLife @mackuba @mastodonmigration @ikuturso @stefan they're not "for-profit" in the traditional sense, being a public benefit corporation (that's what PBC stands for in Bluesky PBC), but in most locales, even your non-profits are technically for-profit corporations.
e.g., Mastodon gGmbH is still a GmbH (especially so when German authorities stripped them of non-profit status due to weird/bad german laws)
-
@breathOfLife @mackuba @mastodonmigration @ikuturso @stefan they're not "for-profit" in the traditional sense, being a public benefit corporation (that's what PBC stands for in Bluesky PBC), but in most locales, even your non-profits are technically for-profit corporations.
e.g., Mastodon gGmbH is still a GmbH (especially so when German authorities stripped them of non-profit status due to weird/bad german laws)
@thisismissem @mackuba @mastodonmigration @ikuturso @stefan
didn't mastodon bother to actually fight that ruling in court though?
that and founding a 501(c)(3) company specifically to get around the tax office.
-
@thisismissem @mackuba @mastodonmigration @ikuturso @stefan
didn't mastodon bother to actually fight that ruling in court though?
that and founding a 501(c)(3) company specifically to get around the tax office.
@breathOfLife @mackuba @mastodonmigration @ikuturso @stefan not sure, but they are currently forming a new EU non-profit. My point still stands that the legal structures are mostly the same: a gGmbH must reinvest in itself instead of pay out to shareholders, and a PBC needs to create benefit for the public instead of for shareholders
-
Recently there has been a lot of discourse about ActivityPub and AT Protocol which has been quite dividing and heated.
Yesterday at the Social Web CG meeting (the group that maintains the ActivityPub and related specifications), I proposed releasing a statement that counters the narrative that one of these protocols must win, when both protocols can co-exist and have a lot to learn from each other.
The statement has been co-signed by various members of both Social Web CG, SocialCG, and the AT Protocol community.
“We do not win by tearing each other down, which only emboldens and empowers those who do not want either protocol to succeed.”
“Arguing between us only emboldens those that seek to derail and destroy efforts to build an open social web.”
You can read the full statement here:
https://github.com/swicg/general/blob/master/statements/2025-09-05-activitypub-and-atproto-discourse.md@thisismissem@hachyderm.io the at protocol is defined entirely by bluesky, which is a centro-fascist authoritarian-supporting highly enshittifiable corporate clusterfuck, which makes me very hesistant to say the least to give it the benefit of the doubt
-
@thisismissem@hachyderm.io the at protocol is defined entirely by bluesky, which is a centro-fascist authoritarian-supporting highly enshittifiable corporate clusterfuck, which makes me very hesistant to say the least to give it the benefit of the doubt
@thisismissem@hachyderm.io if cooperation is what we want then we should all use a single federation standard, and that standard is ActivityPub, especially considering this:
There is an entire section of the ActivityPub specification that isn't as well known or widely adopted but which, at a high level, provides fairly similar ideas to those emphasized within the AT Protocol community for separation between data, identity and applications.
So AT is just ActivityPub but different and 99.5% centered around a hostile corporate entity. Yuh-uh. Count me uninterested
-
@thisismissem@hachyderm.io if cooperation is what we want then we should all use a single federation standard, and that standard is ActivityPub, especially considering this:
There is an entire section of the ActivityPub specification that isn't as well known or widely adopted but which, at a high level, provides fairly similar ideas to those emphasized within the AT Protocol community for separation between data, identity and applications.
So AT is just ActivityPub but different and 99.5% centered around a hostile corporate entity. Yuh-uh. Count me uninterested
@soop that part of the specification is only just starting to really be developed out. Like, the taskforce to work on that was started on friday, and prior to that there'd only been a few experiments done by various people in the community.
That is to say, we're not there yet, and the protocols have slightly different tradeoffs still.
-
@soop that part of the specification is only just starting to really be developed out. Like, the taskforce to work on that was started on friday, and prior to that there'd only been a few experiments done by various people in the community.
That is to say, we're not there yet, and the protocols have slightly different tradeoffs still.
@thisismissem@hachyderm.io the statement you're linking to states that bit of the spec already "is", so that's misleading if anything
anyho i would rather support the ethical option that is decentralized now than the unethical centralized one that honestly also feels like a ploy to fracture the community.
the whole "both protocols should coexist" thing only makes sense if all platforms unconditionally federate via both at the same time, and at that point just put effort towards extending the mature and actually decentralized activitypub instead. there's no point to having another protocol that is corporate-ran and has no chance of becoming meaningfully decentralized before AP is extended to be just as good from a technical PoV
-
@thisismissem@hachyderm.io the statement you're linking to states that bit of the spec already "is", so that's misleading if anything
anyho i would rather support the ethical option that is decentralized now than the unethical centralized one that honestly also feels like a ploy to fracture the community.
the whole "both protocols should coexist" thing only makes sense if all platforms unconditionally federate via both at the same time, and at that point just put effort towards extending the mature and actually decentralized activitypub instead. there's no point to having another protocol that is corporate-ran and has no chance of becoming meaningfully decentralized before AP is extended to be just as good from a technical PoV
@soop so there already is C2S and the ability to read from collections, inboxes, actors, etc.
ActivityPub API takes that a step further and makes sure we tackle the authentication and authorization concerns, handle things like media uploads, better filtering of collections, etc.
As for co-existing, see bridgyfed, you don't need to necessarily simultaneously implement both protocols when bridging is possible.
