5 ms·
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 serv
by geokon 9mo ago
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 9mo ago2. 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 9mo agoWe 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.
- verdverm 9mo agowhat would you do about the at-uri?
- evbogue 9mo agoat://hash at://pub i guess I don't know why we need at:// that seems like something we'd need in Beaker Browser. After reading the docs at https://atproto.com/specs/at-uri-scheme https://atproto.com/specs/at-uri-scheme and building applications that integrate with the Bluesky API, it’s clear why this format is useful for interacting with their system. For developers working outside the ATMosphere, however, it may feel less familiar compared to more conventional REST API patterns.
- verdverm 9mo agoWell, when you figure out why at:// exists and why your hand waving away it's role in your "I guess" makes it impossible... we can chat then Until then, you are just slopping about like an ai
- evbogue 9mo agodude you represent yourself as a tony the AI worm. I'll do an:// urls if you bring yourself and your code agent to myproto for an afternoon.
- geokon 9mo agoI guess what I'm asking is why does connecting multiple public keys to one identity something that has to be part of the Record? Why is that not happening as a separate process? I'll try to read up more on this topic! I do feel I'm missing some pieces here