381–390 of 493 posts
It seems like blue sky is fun right now because it’s exclusive. There doesn’t seem to be anything fundamental to the technology that differentiates the experience from Twitter.
It seems like you're conflating the technology with the user experience. Yes, the user experience is similar. No, the technology underpinning it isn't.
Earlier quoted context omitted.
Reading this I hear someone passionate about technology for the sake of technology. Which is cool, I totally get the desire to build things oneself, but it doesn't really address the substantive questions people are asking about AT: An open protocol exists that broadly does what you want to do. That protocol is stable and widely used. That in itself, regardless of the quality of the protocol, already represents an OK…
It's weird to me that all the complaints about @proto being NIH focus on ActivityPub when if anything it's closer to an evolution of secure scuttlebutt. The two are so fundamentally different I do not understand the complaints.
SSB is also decentralised, while ATProto is federated - like ActivityPub.
Earlier quoted context omitted.
For what it's worth, when a server does go down and thousands of people start uploading their 50k skeets that all need to be cryptographically verified, other major servers will have quite the scaling challenge. Cryptographic verification is intentionally compute heavy after all. 50k entries isn't a whole lot but as people hosting Mastodon servers have found out, things start slowing down when 1000 people transfer th…
Mastodon does not currently support importing posts from your old account. Just followers/following. It's a nuisance, and there's nothing preventing it per se, since the posts are signed, but that part could be better.
Earlier quoted context omitted.
> ActivityPub is incredibly chatty. > ATProto is a better looking protocol already. Are there benchmarks for this? What's the level of difference here? Request frequency seems closely linked to activity and XRPC bodies are JSON just as ActivityPub so message size should be within order of magnitude at least. Are there architectural differences that reduce request frequency significantly? > If this had to scale to a l…
One example of the chattiness is a flow where more than one person is following the same individual on another server. That person will have to push new messages to every single one of the people following them. This means that if 10 users are following me from the same server I will not have 1 push for that instance, I'll gave 10 pushes for the same single unchanged message. This is built into the protocol. That's a…
I think the weirdness is with Bluesky all that cost is still there but it's now handled by a small group of massive megacorps which is a real tangible benefit to self-hosters but you could have that on top of AP by running your service off what would essentially be a massive global cache of AP content which is what the indexer is.
Earlier quoted context omitted.
This is a great summary of what my concerns are as well. I'd maybe add one more point: * Improvements that'd layer cleanly on top of ActivityPub if they'd made any attempt at all. E.g. being able to "cheaply" ensure that you have a current view of all a given users objects is not covered in ActivityPub - you're expected to basically want to get the current state of one specific object, because most of the time that i…
Your added point fits in with the initial red flag for me - before I saw pfraze's (excellent) post here - that the vast majority of what I've read advocating for ATProto says very clearly: "Account portability is the major reason why we chose to build a separate protocol.". Account portability is in no way incompatible with ActivityPub. It's not built into the spec., but it's also not forbidden / prevented by the spe…
Earlier quoted context omitted.
What about images in tweets?
Sites such as Imgur and Giphy were created to solve this problem. A lot of users simply don't know or don't recall just how barebones the original Twitter app was.
One thing I do like about the decentralized model is the ability to modularize this.
I would love a Bluesky/ATProto/whatever client that allowed me to specify some compatible image service where images I post get seamlessly uploaded and linked.
Then I can choose what I use, maybe it's something I pay for and have better guarantees around durability and availability.
Or maybe it's a free or ad-supported service where my image gets deleted after 6 months and I don't care that's fine with me.
Giving users more choices is good, IMO.
Earlier quoted context omitted.
What about images in tweets?
Most users probably have the pictures they uploaded to Twitter still stored on their phone without having a capacity issue due to them.
Earlier quoted context omitted.
Your added point fits in with the initial red flag for me - before I saw pfraze's (excellent) post here - that the vast majority of what I've read advocating for ATProto says very clearly: "Account portability is the major reason why we chose to build a separate protocol.". Account portability is in no way incompatible with ActivityPub. It's not built into the spec., but it's also not forbidden / prevented by the spe…
An unspecified "implementation detail" is essentially another way of saying that it doesn't work. I've ported my account on ActivityPub a couple time, and it's a horrendous experience -- not only do I lose all my posts and have to manually move a ton of bits, but the server you port from continues to believe you have an account and doesn't like to show you direct links on there anymore. The latter could probably be e…
> the former needs to be built into the spec or it will continue to be broken.
Absolutely, but ActivityPub doesn't preclude that. There's no reason for that proposed feature to be incompatible with the spec., or to have to exist in an implementation that is incompatible with ActivityPub.
Fwiw Mastodon, the most popular ActivityPub implementation, is (as is often the case with open standards) not actually fully compliant with the spec. They implement features they need as they need & propose them. This is obviously a potential source of integration pains, but as long the intent to be compatible is still there, it's still a better situation.
Earlier quoted context omitted.
I run a single user ActivityPub instance with a minimal following and small number of people across multiple instances that I follow. From a user perspective ActivityPub is fine I have no complaints. However from an Ops perspective ActivityPub is incredibly chatty. If this had to scale to a larger instance the costs would spiral fast. Operationally and cost efficiency wise ATProto is a better looking protocol already…
Being technically better is usually not a good enough reason to be incompatible. I'm not sure why people don't get this, but it is almost always true. Starting from scratch, just because you can theoretically design a better system, is one of the worst thing to do to users. Theoretically better also rarely wins in the marketplace anyway. If you want a slightly lighter position: Software needs to be built to be migrat…
The whole point is that it needs to be reasonably easy for people to run and scale their own servers. If people are constantly being burned out, quit, or run out of money, then it has an impact on regular users.
Earlier quoted context omitted.
> ActivityPub is incredibly chatty. > ATProto is a better looking protocol already. Are there benchmarks for this? What's the level of difference here? Request frequency seems closely linked to activity and XRPC bodies are JSON just as ActivityPub so message size should be within order of magnitude at least. Are there architectural differences that reduce request frequency significantly? > If this had to scale to a l…
One example of the chattiness is a flow where more than one person is following the same individual on another server. That person will have to push new messages to every single one of the people following them. This means that if 10 users are following me from the same server I will not have 1 push for that instance, I'll gave 10 pushes for the same single unchanged message. This is built into the protocol. That's a…
I haven't implemented AP from scratch so I may be missing technical details precluding this, but it sounds like it may at least partially be covered by https://www.w3.org/TR/activitypub/#shared-inbox-delivery
... in which case it may be an implementation issue?
Mind you, there is liberal use of "MAY" there which I find is always a problem with specs: that would likely lead to mandatory chattiness of outgoing requests if you're federated with a lot of instances without shared inbox support, but should at least solve for incoming.