331–340 of 493 posts
Earlier quoted context omitted.
Sure, but that's not really compatible with the "quiet, stealthy beta" thing OP claims they were aiming for. If it was meant to be a quiet beta journalists should probably have been invited at a later point.
It’s a waitlist plus invite codes given to users. We have had only a vague influence over who joined.
Okay well. I work on Bluesky and helped build the AT Protocol. I'm sorry Sam differs with us on this, and I'm glad that Activity Pub is already there for him. However, Sam doesn't understand the ATProto very well and I want to clear it up a bit. Before I do, let me just say: Bluesky and the AT Proto are in beta. The stuff that seems incomplete or poorly documented is incomplete and poorly documented. Everything has m…
for some reason people think what we have now is good, and they say "dont reinvent the wheel" but there is no wheel, what we have is just garbage, 50 years and later we still cant beat the "unix pipe"
we have to keep trying to make a wheel
Earlier quoted context omitted.
They're explicitly not debating in good faith: "Also I don't care if I'm spreading FUD or if I'm wrong on some of this stuff. I spent an insane amount of time reading the docs and looking at implementation code, moreso than most other people. If I'm getting anything wrong, it's the fault of the Bluesky authors for not having an understandable protocol and for not bothering to document it correctly." ( https://urbanis…
Yeah the way he conflates "crypto" to refer both cryptography and cryptocurrency, and the rhetoric itself is quite odd: https://urbanists.social/@sam/110340265606422596 It's unfortunate because there are some valid points in his criticism.
Earlier quoted context omitted.
Not having read the article, I got pretty far into your second paragraph before realizing you all aren't talking about configuring a modem over a serial link. It's funny because the "Hayes AT command set" protocol is also an obtuse crock. I was really hoping you were going to open my mind with some deep wisdom straight out of 1981.
> the "Hayes AT command set" protocol is also an obtuse crock Yeah, but it's an obtuse crock that you can literally still here in your memories. How many protocols can say that? It has a special place in my heart, I think.
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…
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…
> 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 larger instance the costs would spiral fast.
Are we talking bandwidth costs or processing. I know the popular ActivityPub implementation is widely considered to be pretty inefficient processing-wise for reasons unrelated to the protocol itself: is that a factor here?
Earlier quoted context omitted.
Not having read the article, I got pretty far into your second paragraph before realizing you all aren't talking about configuring a modem over a serial link. It's funny because the "Hayes AT command set" protocol is also an obtuse crock. I was really hoping you were going to open my mind with some deep wisdom straight out of 1981.
> Hayes AT command set" protocol is also an obtuse crock. I will nake sure to reuse this name if I ever find myself developing an Obtuse crock.
Earlier quoted context omitted.
> the "Hayes AT command set" protocol is also an obtuse crock Yeah, but it's an obtuse crock that you can literally still here in your memories. How many protocols can say that? It has a special place in my heart, I think.
I keep a Hayes Smart Modem 300 within arm's reach of my desk just in case.
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…
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…
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 spec. in any way. From ActivityPub's perspective it's an implementation detail.
Would it be nice if it was built into the spec: yes. Does that justify throwing out the baby with the bathwater?
I was hoping pfraze would offer some better reasoning, but while the post above is a great read for the technically curious, its very "in the weeds" so doesn't really address the important high-level questions. Textbook "technologists just want to technologise" vibes: engineers love reinventing things because working out problems for yourself is the fun part, even if many people have come together to collaborate on solving those problems before.
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…
Earlier quoted context omitted.
How did we get to 55k tweets being a nightmare for any social media platform? A quick search got me to twitter stats from 2013 when people were posting 200 billion tweets per year. Thats 5-6 orders of magnitude more. You don't get a 10000x improvement just by federating and hosting multiple nodes.
The discussion here was about archiving each user's tweets on their own client device - this is where the 55k was brought up as a problem. I still think it's a low number, even if it includes plenty of images.