This was a nice intro to AT (though I feel it could have been a bit shorter)

The whole things seems a bit over engineered with poor separation of concerns.

It feels like it'd be smarter to flatten the design and embed everything in the Records. And then other layers can be built on top of that

Making every record includes the author's public-key (or signature?). Anything you need to point at you'd either just give its hash, or hash + author-public-key. This way you completely eliminate this goofy filesystem hierarchy. Everything else is embed it in the Record.

Lexicons/Collections are just a field in the Record. Reverse looking up the hash to find what it is, also a separate problem.

▲ evbogue 8 hours ago | parent | next [-]

Yes. SSB and ANProto do this. We actually can simply link to a hash of a pubkey+signature which opens to a timestamped hashlink to a record. Everything is a hash lookup this way and thus all nodes can store data.

▲ danabramov 7 hours ago | parent | prev [-]

I'm not sure I understand your proposal. Do you taking my example (a Twitter post) and showing how it would be stored in your system?

▲ geokon 6 hours ago | parent [-]

Sure, you'd have something like:

    {:record   {:person-key **public-key** 
                :type :twitter-post
                :message "My friend {:person-key **danabramov-public-key**} suggested I make this on this HN post {:link **record-of-hn-post-hash**}. Look at his latest post {:link **danabramov-newtwitter-post-hash** :person-key **danabramov-public-key**} it's very cool!"}
    :hash      **hash-of-the-record**
    :signature **signature-by-author**}

So everything is self-contained. The other features you'd build on top of this basic primitive

- Getting the @danabramov username would be done by having some lookup service that does person-key->username. You could have several. Usernames can be changed with the service.. But you can have your own map if you want, or infer it from github commits :)) There are some interesting ideas about usernames about. How this is done isn't specified by the Record

- Lexicon is also done separately. This is some validation step that's either done by a consumer app/editor of the record or by a server which distributes records (could be based on the :type or something else). Such a server can check if you have less than 300 graphemes and reject the record if it fails. How this is done isn't specified by the Record

- Collection.. This I think is just organizational? How this is done isn't specified by the Record. It's just aggregating all records of the same type from the same author I guess?

- Hashes.. they can point at anything. You can point at a webpage or an image or another record (where you can indicate the author). For dynamic content you'd need to point at webpage that points at a static URL which has the dynamic content. You'd also need to have a hash->content mapping. How this is done isn't specified by the Record

This kind of setup makes the Record completely decoupled from rest of the "stack". It becomes much more of independent moveable "file" (in the original sense that you have at the top) than the interconnected setup you end up with at the end.

▲

danabramov 6 hours ago | parent [-]

I have a few questions:

- How do you rotate keys? In AT, the user updates the identity document. That doesn't break their old identity or links.

- When you have a link, how do you find its content? In AT, the URL has identity, which resolves to hosting, which you can ask for stuff.

- When aggregating, how do you find all records an application can understand? E.g. how would Bluesky keep track of "Bluesky posts". Does it validate every record just in case? Is there some convention or grouping?

Btw, you might enjoy https://nostr.com/, it seems closer to what you're describing!

▲

geokon 6 hours ago | parent [-]

1. It's an important problem, but I think this just isn't done at the Record layer. Nor can you? You'd probably want to do that on the person-key->username service (which would have some log-in and way to tie two keys to one username)

2. In a sense that's also not something you think about at the Record level either. It'd be at a different layer of the stack. I'll be honest, I haven't wrapped my head entirely around `did:plc`, but I don't see why you couldn't have essentially the same behavior, but instead of having these unique DID IDs, you'd just use public keys here. pub-key -> DID magic stuff.. and then the rest you can do the same as AT. Or more simply, the server that finds the hashed content uses attached meta-data (like the author) to narrow the search

Maybe there is a good reason the identity `did:plc` layer needs to be baked in to the Record, but I didn't catch it from the post. I'd be curious to here why you feel it needs to be there?

3. I'm not 100% sure I understand the challenge here. If you have a soup of records, you can filter your records based on the type. You can validate them as they arrive. You send your records to the Bluesky server and they validates them as they arrive.

▲

verdverm 3 hours ago | parent [-]

2. The point of the PLC is to avoid tying identity to keys, specifically for the point that if you lose your keys, you lose your identity. In reality, no body wants that as part of the system

3. The soup means you need to index everything. There is no Bluesky server to send things to, only your PDS. Your DID is how I know what PDS to talk to to get your records

	▲	evbogue 2 hours ago \| parent [-]
		We can have both a directory and use content addressable storage and give people the option of using their own keypairs. They are not mutually exclusive. Bluesky chooses to have a central directory and index.