Hacker News: thisismissem

New comment by thisismissem in "We moved our Bluesky data to Eurosky"

thisismissem — Tue, 30 Jun 2026 18:10:33 +0000

I used to work for timbl's company Inrupt on Solid on the SDK team. Inrupt no longer appears to be doing solid (or at least it's very well hidden if it still exists).

AT Protocol achieved what Solid envisioned without the inane complexities of rdf and json-ld, which were the biggest learning blockers to people actually adopting Solid.

New comment by thisismissem in "Where it's at://"

thisismissem — Sat, 04 Oct 2025 01:33:22 +0000

That is a risk for did:web, just as loosing control of your domain is a risk; The did method that is most widely used on AT Protocol is did:plc, which is https://web.plc.directory/

There's also did:webvh which isn't yet supported by AT Protocol, but may provide some better security, but is likely still susceptible to DNS poisoning.

However, the resolution of handle to DID happens at many different layers in the stack, so you'd have to manage to attack all of them at once. Handle resolution isn't something that typically happens on the end-users' machine, but rather on a server running a PDS, Relay or AppView. Those environments tend to be much harder to carry out DNS poisoning attacks.

New comment by thisismissem in "Where it's at://"

thisismissem — Sat, 04 Oct 2025 01:18:49 +0000

If you did hijack the DNS and say `TXT _atproto.` points to `did:web:mycontrol.example` then that's a plausible attack, I guess, against did:web, but not against did:plc. And it'd assume that software in between hasn't cached the previous mappings, which typically it has.

This is noted in the did:web spec, which isn't from Bluesky PBC / AT Protocol: https://w3c-ccg.github.io/did-method-web/#dns-considerations

I should note though, that for many implementations, that'd mean poisoning a large DNS provider like google, cloudflare or quad8, since those are the DNS servers typically queried from servers, instead of going directly to the authoritative server itself.

There's more technical details here: https://github.com/bluesky-social/atproto/tree/main/packages...

New comment by thisismissem in "Where it's at://"

thisismissem — Sat, 04 Oct 2025 01:05:48 +0000

They'd need the private key to post as you. The DNS record just points to where the DID document is, but there's a verification check that the DID document points back, and this is automatically performed as a part of the resolution process.

DNSSEC would add additional security around DNS record changes, but not having it wouldn't allow someone to impersonate you, because your server would need to agree with that.