Ha! Opened this wondering why someone would still be griping about the old Hayes AT modem command set - some 20 to 30 years later! :)
The AT protocol is the most obtuse crock of shit
401–410 of 493 posts
Re: The AT protocol is the most obtuse crock of shit
#402Earlier quoted context omitted.
> Why bother with Mastodon interop? Why bother building on top of a standard that doesn’t do what you want if you don’t think being part of the “Fediverse” is particularly interesting or a goal of the platform you’re building? Because they pretend to want to be open, and it's sending a very clear signal that is not their goal if they're not even trying to work with the existing ecosystem. If they just want to be a si…
Er why are you conflating “being open” with “being part of the Fediverse”? The Fediverse has no monopoly on that notion, and in fact shaming folks for not wanting to integrate with it is the opposite of open. It’s like saying “BSDs pretend to be open, but they’re not even trying to be compatible with Linux”.
Making a conscious choice about differences is fine. The BSDs and Linux share many things, and not other, on the basis of different goals. They're not different for the sake of being different. The vibe I'm getting from the way AT is different is that they're different for the sake of being different.
Re: The AT protocol is the most obtuse crock of shit
#403Earlier quoted context omitted.
Isn't that "more than once instance" rather than "more than one user"? 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.
Yes, I edited my comment too be more clear and. I shouldn't have referred to it as fetch because it's actually push.
I should note that as a protocol I suspect that ATProto is less chatty which does translate to reduced costs. It adds features on top that some may or may not want which increase costs in other ways but only for the people who want to utilize those features. It's not exactly an Apples to Apples comparison.
Re: The AT protocol is the most obtuse crock of shit
#404Earlier quoted context omitted.
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.
I know, and although I understand why (ActivityPub IDs are generally URLs and changing them would probably cause duplicates, but there are URLs that don't change). It's quite annoying that it can't be done right now, but I'll admit that I also don't care enough to come up with a patch for it.
There are two ways around this:
1. They are URI's, and while ActivityPub say they should be https URL's, they don't need to be, and could e.g. point at IPFS or similar.
2. JSON-LD signatures are used by Mastodon, and included in the export, and nothing stops another instance from validating those and serving them up with the original URIs in the id from new URLs, as a means of making it clear the server didn't originate them (there'd be a trust issue if the other servers is unable to get hold of the keys because the original server is gone, but no more so than if the new server had simply republished the content, so the "worst case" is to distrust the original id's).
There are some corner cases there, around trusting the identity of the old and new account represents the same user, so I do think a recovery key type scheme would be nice to allow a user to prove the old and new id is the same (if changing id; I also think we could really use decoupling the expectation that a webfinger id is inherently tied to a Mastodon account - you can sort of do that today; nothing stops you from serving up a separate webfinger result and use it as an alias, but there are usability issues to solve there).
Re: The AT protocol is the most obtuse crock of shit
#405Earlier 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'm not to into the weeds of activitypub yet but in my head it seems like you could add some things to the protocol to optimize this.
1. server with the sender constructs a map by receiving server that contains a list of all users on that server who should receive the message.
2. sending server iterates the map. If the receiving server has multiple recipients do a check to see if the receiving server supports this kind of 'bundled' delivery.
2a. If so send the message once with a list of receivers.
2b. receiving service processes the one message and delivers it to all the users.
Re: The AT protocol is the most obtuse crock of shit
#406Earlier quoted context omitted.
Makes it really hard to search stuff. This has happened with Matrix, Go. Although using golang resolves issue with Go.
I agree that 'go' has to be the worst naming from an SEO perspective. Only ones worse a single letter names. And TBH, they might be _better_ simply because they aren't a common English language word.
better than .net, admittedly.
Re: The AT protocol is the most obtuse crock of shit
#407> I was like "I'll just make a simple alternative to the BlueSky server in Elixir". But it CAN'T be a simple implementation like ActivityPub can be, because it is extraordinarily complex and requires you to make guarantees about your storage and how your application works. You might suspect that OP has a familiarity bias here but actually there is objective evidence that ActivityPub based implementations are (relativ…
> You might suspect that OP has a familiarity bias here but actually there is objective evidence that ActivityPub based implementations are (relatively) simple: there are dozens of implementations of both servers and clients, will all sorts of functionality that is not emulating the "twitter/mastodon" experience. Heck, even a Wordpress plugin in the works.
AT Protocol has a very active ecosystem already too (even though Bluesky is still invite-only): https://github.com/bluesky-social/atproto-ecosystem
And this isn't a complete list; there's a very active Discord for people doing bluesky projects which currently has 1.2k+ members
Re: The AT protocol is the most obtuse crock of shit
#408Earlier quoted context omitted.
> This is built into the protocol. 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 mandat…
In theory it would help. In practice since a server can't rely on this it probably devolves to just ignoring that feature.
There can be an interrogation endpoint/message of supported versions/extensions to the base protocol, that's a very normal thing. If it supports bundled delivery, send a single bundle if not send them all individually.
Re: The AT protocol is the most obtuse crock of shit
#409Earlier quoted context omitted.
I'm really surprised every time anyone complains that a web-application (not just a plain web site) doesn't work without JS. I mean it's an application, applications contain code and tracking that code state server side can involve a non small amount of additional cost. Sure they could have a web-side like non-logged in viewer mode and then somehow using hydration magic transition to being a app on demand, but that i…
I complain about the content (which is text) being not available. I couldn't care less about the web-application. In general too, but especially here, where people are supposed to share mostly text each other. (We can share web-applications as well, and you won't find me complain there.) At this point I could just flag every mastodon content, since it is not available. Good idea, I will just do that.
> At this point I could just flag every mastodon content, since it is not available. Good idea, I will just do that.
If HN requires sources to be available in no-js only form yes, that would be appropriate, if not it would be abuse of the flagging feature.
Re: The AT protocol is the most obtuse crock of shit
#410It 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.
The technology allows the community to iterate on the experience from twitter. There are already several alternate clients, people have made custom feed algorithms, custom tools and spam-fighting systems, and we're just getting started
The twitter experience has been in decline for years, and took a sharp downward turn when ownership changed. But people on twitter just have to live with it, especially now that the (already limited) API has been closed down almost completely, because it's not an open platform like bluesky. If bluesky ever starts to make the official client a bad experience, or starts to make moderation (or non-moderation!) decisions people don't like, users don't have to just live with it. They can go find or create the experience they want without losing anything