Bluesky, which uses it, has been opened to federation now, and the standard basically just looks better than ActivityPub. Has anyone heard about a project to make a Lemmy-style “link aggregator” service on it?
ha, no… bluesky is not open to federation. they control the only router and do not allow connectivity to routers not controlled by them.
there isnt a single non-bluesky controlled instance that can federate natively with bluesky.
bluesky is just twitter with a little more user-controllable data sourcing. not that theres anything wrong with that, but its certainly not a part of any federation.
e. suggested reading: https://dustycloud.org/blog/how-decentralized-is-bluesky/
I believe the “free our feeds” people are working to change this though.
And they are either in for one of the following:
- a $30 Million lesson where they learn that they will have to reinvent ActivityPub in order to be “properly” decentralized
- a rug pull where they come up with a second relay like Bluesky but fork to give exclusive access for large institutions and the enterprise.
It’s ridiculous they were asking for $30m to do something that ActivityPub already does. Wasted money that could have gone anywhere else
There are important features that ATPro has that activity pub doesn’t. I’d prefer activity pub be the winner but they really need to improve some things. Namely, identity. Bluesky identity is more portable.
We still don’t need ATProto for that. ActivityPods solves that.
ActivityPub itself is built around the principle that the server owns your identity: the best you can do is abandon an identity (i.e, your actor URL) and tell everyone else (via the
MoveActivity) that you are adopting a new identity.
good luck to them. the router piece is incredibly top heavy and not designed for horizontal scaling.
Yep. What do you think the chances are you could write something that does the job of the router and app view, but in a totally off-standard, more point-to-point way?
In the meanwhile, it’s just a matter of bridging, I guess.
the protocol itself creates a barrier to entry preventing other organizations. it puts all the eggs in one basket.
It’s a good blog post, thanks. I made a quick summery elsewhere in the thread.
It’s really unfortunate that we’ve ended up with two populated protocols for federation, both of which have a major flaw. In our case, it’s no established support for moving accounts. In theirs, its a component that’s so bulky the federatability is questionable (and no federated DMs).
both of which have a major flaw
What major flaw do you believe ActivityPub has?
This is such a well written piece, it’s closer to a serious article than a blogpost
agreed. the follow up is just as good.
the standard basically just looks better
Place your bets everyone, has OP ever looked at either standard?
Bets all in? Okay:
spoiler
I have not looked directly at the AT standard, just the Wikipedia article and some similar high-level explanation.
Pretty sure I have actually looked at the ActivityPub standard at times, though.
Very slow at the moment, probably due to people looking for Reddit alternatives but was fine couple of weeks ago when I first saw it. Seemed okay if you’re okay with AT Proto (it’s not that decentralised really).
Really? In what way?
Digital identities being cryptographic and independent of any one instance is huge all on it’s own. The rest of it I understand less clearly, but it looks pretty modular.
See here. Basically, creating a relay for the AT protocol is extremely costly and only possible for big tech companies.
Thank you!
TL;DR, the relay bit works as a completely connected network topology, and has the associated quadratic growth issues, which renders it, like you said, hard to host.
Also nasty: Direct messages are just not federated.
Other things are or were at the time of writing janky, but nothing else is quite that egregious. The author is working on a separate project, and recommends this idea as a solution for portable identity on ActivityPub; here’s what “object capability” means in the context.
The data is not centralized, but everyone is using the same
aggravationaggregation service (indexer) to access the data.Don’t aggregate me pal
LOL I should have reread that one.
Most aggregation services are also aggravation services, so this really makes sense either way.
There’s also this:
https://frontpage.fyi/Not sure which of the two has been around longer, but looks like frontpage is also pretty slow going.
It’s very difficult to use. As a dev, it’s not the greatest.
Oh? Complicated, fragile, something else?
The spec requires a huge relay for everything as well as not the greatest docs/missing pieces.
Ah yes, the wonders of OSS documentation.
Bluesky should just turn on ActivityPub at this point
Leaving aside all the work they did making an alternative more to their liking, that kind of implies it’s like a light switch, and it’s not.
I wish they would but also ATPro has features that activity pub doesn’t, ones which I think activity pub needs to adopt if it is to stay relevant
If Bluesky becomes federated with multiple instances, it will be just as impossible to enter as ActivityPub-based services apparently are since instance-selection is a blocker.
RIght?
;)
Yep, probably. People are just going to have to get used to it to certain degree, and to a certain degree there’s going to be .world-type instances that act as a user-friendly default.
There’s other issues at play, of course, which is more why I asked.
looks better
What do you mean?
than ActivityPub
ActivityPub is decentralised. AT has a centralised index. They’re not comparable.
