301–310 of 493 posts
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.
Yes, I came for a critique of the Hayes AT commands.
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.
You sound like you may also be old enough to remember dealing with AT keyboard scan codes directly.
Earlier quoted context omitted.
The issue there is that journalists is a good reason why Twitter became mainstream, it makes sense to invite them to your Twitter clone
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.
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…
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.
Earlier quoted context omitted.
> Using this model one can pull content from _anywhere_ without having to worry about MITM forgeries etc Does that makes it more difficult to implement the right to be forgotten and block spam and trolls?
Doesn't it make it easier? A list of hashes which should be blacklisted means servers obeying rulings are never at risk of returning that data (this would also work offensively: poll for forbidden hashes and see who responds).
It makes life really easy for spammers.
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…
My reaction whenever I see such headline is always "there must be an engineer out there who worked on this, I wonder how they feel about this". I had the same reaction today, opened comments and you were at the top. I love HN sometimes.
That said, my frustration still gets converted into not-so-polite comments in the source code the culprits will never see.
Earlier quoted context omitted.
But to model mutable things over and immutable blocks you need to revalidate which blocks are still valid. You need to know that the user expects you to now have a different view. That you're not mutating individual blocks but replacing them has little practical value. It'd be nice to implement a mechanism that made it easier to validate whole collections of ActivityPub objects in one go, but that just requires addin…
> you need to revalidate which blocks are still valid. No you don't. Sorry if I'm misunderstanding, but it sounds like maybe you don't have a clear idea of how systems like git work. One of their core advantages is what we're talking about here -- that they make replication so much simpler. When you pull from a git remote you ask the remote what the root hash is, then you fetch all the chunks reachable from that hash…
Yes, I know how Merkle trees work, what it allows you to do. In other words you use the hash to validate which blocks are still valid/applicable. Just as I said, you need to revalidate. In this context (a single user updating a collection that has an authoritative location at any given point in time) it effectively just serves a shortcut to to prune the tree of what you need to consider re-retrieving in this context.
It is also exactly why I pointed at RemoteStorage, which models the same thing with a tree of etags, rooted in the current state of a given directory to provide the same shortcut. RemoteStorage does not require them to be hashes from a Merkle tree, as long as they are guaranteed to update if any contained object updates (you could e.g. keep a database of version numbers if you want to, as long as you propagate changes up the tree), but it's easy to model as a Merkle tree. Since RemoteStorage also uses JSON-LD as a means to provide directories of objects, it provides a "ready lift" model for a minimally invasive way of transparently adding it to an ActivityPub implementation in a backwards compatible way.
(In fact, I'm toying with the idea of writing an ActivityPub implementation that also supports RemoteStorage, in which case you'd get that entirely for "free").
> (I mean simple in the sense of clear/direct/correct, not in the sense of "easy". It's certainly the case that a design based on consuming a stream of change events is a lot less code).
That is, if anything, poorly fleshed out in ActivityPub. In effect you want to revalidate incoming changes with the origin server unless you have agreed some (non-standard) authentication method, so really that part could be simplified to a notification that there has been a change. If you layer a merkle like hash on top of the collections you could batch those notifications further. If we ever get to the point where scaling ActivityPub becomes hard, then a combination of those two would be an easy update to add (just add a new activity type that carries a list of actor urls and hashes of the highest root to check for updates).
Earlier quoted context omitted.
Ok, so add some more megabytes to that. Most people don't have that much microblogging data.
I actually think photos could potentially add up to quite a lot!