361–370 of 493 posts
Earlier quoted context omitted.
Yeah, I wish they hadn't clobbered the name of an existing, well-known protocol. It's still used in drivers for cellular modems (I'm working with it right now), which are getting more and more numerous for IoT applications.
It's a cheeky way to say @ protocol.
Earlier quoted context omitted.
Sure nothing stops you doing those things, but also nothing makes them seem like a good idea. 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? Something new is a better bet at this point than being anchored to or seeming like part of Mastodon I…
> 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…
No matter how open I wanted to be, if I was setting out to build a social network, I’d please precisely zero value on being connected to that “existing network”.
It is irrelevant to me, despite what a vocal minority might want me to believe.
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…
From a purely technical analysis ATProto looks better as a protocol to me. But I don't use Bluesky I use ActivityPub because the people I want to be connected to are there and not on Bluesky. I do think you could probably make improvements to ActivityPub that reduce operational costs. It's not something I feel the need to tackle right this moment because my usage doesn't incure those costs really.
Earlier quoted context omitted.
I have not looked much at AT, but it seems it solves many of the same problems as Matrix. Instead of redoing all the Crypto and everything, why not build on martrix. There were other Twitter like things on Matrix before. As far as I'm aware its developed on Matrix and had some connection with it, so this isn't a case of not knowing about it so there is likely some engineering reasons why this was not done. Would be i…
AT proto has some significant similarities to Matrix: * Both are work by self-authenticating git-style replication of Merkle trees/DAGs * Both define strict data schemas for extensible sets of events (Matrix uses JSON schema - https://github.com/matrix-org/matrix-spec/tree/main/data/eve... and OpenAPI; AT uses Lexicons) * Both use HTTPS for client-server and server-server traffic by default. * Both are focused on dec…
It’s refreshing to see this perspective, and I appreciate trying to quash the us-vs-them thing, so thanks.
Earlier quoted context omitted.
There's a discourse clash. AT and Bluesky are unfinished. Not ready for primetime. It's not fair to compare it to mature, well-developed stuff with W3C specs and millions of active users on thousands of servers with numerous popular forks. But, also, everyone who hates Mastodon and spent the last months-years complaining about it is treating your project like the promised land that will lead them into the Twitterless…
> It's not fair to compare it to mature, well-developed stuff Really? So rather than try to compare, contrast, and course-correct a project in its early stages by understanding the priors and alternatives, we should only do retrospectives after it has matured? I would have thought this was the whole point of planning in early development: figuring out what you actually need to make? And that is usually a relative pro…
It's not that bad. ATZ and ATDT are the main two you have to remember. Wait, is that not what we're talking about? So, it has a confusing name too?
> "Imagine if I had to store the 50k+ tweets I've made on Twitter on my device, and upload ALL of them to a new server whenever a community server went down." This... doesn't seem too bad at all? Let's assume an average of 150 bytes of text per tweet, and an additional 50 bytes of actually important metadata. That's only 10 megabytes for the entire archive of 50,000 items. A single HDR photo from a modern smartphone…
It's fascinating the Twitter we have today and the Twitter from that era are even considered the same app. I wrote a simple Twitter client in Cocoa and Python and even NodeJS. It was such a simple way to get a working, functional, usable demo going that you could immediately show to friends.
Then they realized it's impossible to make money advertising this way and shut it down.
> "Imagine if I had to store the 50k+ tweets I've made on Twitter on my device, and upload ALL of them to a new server whenever a community server went down." This... doesn't seem too bad at all? Let's assume an average of 150 bytes of text per tweet, and an additional 50 bytes of actually important metadata. That's only 10 megabytes for the entire archive of 50,000 items. A single HDR photo from a modern smartphone…
What about images in tweets?
A lot of users simply don't know or don't recall just how barebones the original Twitter app was.
Earlier quoted context omitted.
> The schema is a well-defined machine language which translates to static types and runtime validation through code generation. Can you elaborate on this point? There's multiple mature solutions in this space like OpenAPI+Json Schema, GraphQL, gRPC. All try to solve the same problems to varying degrees and provide similar benefits like generated static typed and runtime validation. Was there something unique for you…
I don't know what AT is doing but I can say that while JSON Schema is okay as a validation schema it is less okay as codegen schema. I don't know if there is a fundamental divide between these two uses but in JSON Schema there is definitely an impedance mismatch. For example, the JSON Schema structures: `anyOf`, `oneOf` and `allOf` are fairly clear when applied toward validation. But how do you map these to generatin…