Comment by geokon

9 hours ago

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.

7 comments

geokon

Reply
evbogue  9 hours ago

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  8 hours ago

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  7 hours ago

    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  7 hours ago

      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!

      3 replies →