did:key: is a 256 bit base58btc
publicKeyMultibase 512 bit base58btc

https://medium.com/asecuritysite-when-bob-met-alice/02-03-or-04-so-what-are-compressed-and-uncompressed-public-keys-6abcb57efeb6

Two things:

1. you jumped to "mutable data" when I was talkin' about immutable. :P
2. but if we look at the mutable case. The master "record" be a single list of all the root merkels for every month of a person's life. What that means is each "rolled up" monthly chunk of data can be updated and it simply results in a new root merkle hash for that one month ZIP/CAR file.

The benefit if the "by month" approach is that when I want to follow someone, I don't get ALL their data unless I ask for it...but I do always get that "master record" which is essentially a list of monthly hashes.

for
at://repo_did@commit_hash/collection/record_tid
or
at://handle@commit_hash/collection/record_tid
the "big index of record-CID to commit" is not like searching IPFS the RepoID (DID or handle) is also there so you can look up the home server and then pass the url with the commit_hash to it.
The home server is the one that keeps the old commits, path nodes, and records to return for a uri request. Or it can respond that this record has been deleted. Probably we would want it to return not only the exact record but the current record for the same path in the latest repo.

This also serves as a guard agents the handle being reassigned by the DNS system. If the commit hash matches then it is the content that was the handle at the time the link was generated. Irrespective of wether the publisher later decided to stop paying their DNS name bill.

Fun things you can do already, once you export your repo to a car file (using com.atproto.sync.getRepo) you can import that into ipfs and explore the data:

123456789why@sirius ~/c/gosky (master)> ipfs dag import repo.car
Pinned root	bafyreiejwkm2e5j2cf7ft5gt673bkjb56qkhm5r7ylddzjvarcf6pm3awe	success
why@sirius ~/c/gosky (master)> ipfs dag get bafyreiejwkm2e5j2cf7ft5gt673bkjb56qkhm5r7ylddzjvarcf6pm3awe
{"root":{"/":"bafyreifslfzyxiaqeaeeoydnb7fwmxq7cwjqrqtbvjw2rbq7ibarnl4fui"},"sig":{"/":{"bytes":"aaRPVJa/QRbhCOuUTJS8M7x/KEgpBW25HHfLVZvB9bTqrfDNMuESuVdxdT1SbV0p5FfVFpYLsL5KyXejjTP2dA"}}}
why@sirius ~/c/gosky (master)> ipfs dag get bafyreifslfzyxiaqeaeeoydnb7fwmxq7cwjqrqtbvjw2rbq7ibarnl4fui
{"auth_token":null,"data":{"/":"bafyreife3hhlk6ukkpjjvp3fmn4eocqfczlf472kgjgzfygz3bjsw43l3u"},"meta":{"/":"bafyreidevl4oqvw4gfoxnyctsr373zi7dnnj4pjkbh4nclubkqaf37vtvq"},"prev":{"/":"bafyreigc5zp7rzfuuxoylmbsdj4meog6esxuqgpehty6g466f2flxnj4ra"}}⏎                                                                                                       why@sirius ~/c/gosky (master)> ipfs dag get bafyreife3hhlk6ukkpjjvp3fmn4eocqfczlf472kgjgzfygz3bjsw43l3u
{"e":[{"k":"app.bsky.feed.post/3jgwsf5q64c2z","p":0,"t":null,"v":{"/":"bafyreig4s2bn7yjo2i2r2gut7uvxvvcgsyf4jcyndcbnjdm5jkjx35o6yu"}},{"k":"tjxhkc2z","p":24,"t":null,"v":{"/":"bafyreiduauw76xk4gz3srdhdnkwzmwuisviqp72nyia3crklgxwhddv7ga"}},{"k":"system.declaration/self","p":9,"t":null,"v":{"/":"bafyreid27zk7lbis4zw5fz4podbvbs4fc5ivwji3dmrwa6zggnj4bnd57u"}}],"l":null}
why@sirius ~/c/gosky (master)> ipfs dag get bafyreiejwkm2e5j2cf7ft5gt673bkjb56qkhm5r7ylddzjvarcf6pm3awe/root/data/e/0/v
{"$type":"app.bsky.feed.post","createdAt":"2022-11-07T11:04:03-08:00","text":"i like cats and dogs too"}

bnewbold: I had been using publisher as handle or DID

Mostly just trying to get away from host.
The origin for https is protocol, hostname, and port. The origin for ATP is protocol and publisher. We don't care what host gave it to you just if the signature is valid.

Actor is pretty generic and has some overlap with the Erlang model but I don't know as long as we pick something and use it constantly probably fine. As long as we are clear what the origin is for the same origin policy

¯_(ツ)_/¯

url = new URL('http://example:8080/path') url.hostname // "example" url.host // "example:8080"

Hey Prashant, I'll answer here instead of twitter DMS.

1. No, you can host as many as you want. The signing key gets reused across repos. This is done so that PDSes can use the secure key managers that cloud services provide, which cost too much money per keypair to support 1 key per account.
2. That is possible but you'd need to customize the PDS software to do that. Our implementation expects writes to be handled by the "home" PDS. You could make a version that is declared as the home PDS but actually just rehosts the current repo, allowing the signed updates to come from somewhere else.

This is not currently a priority and not on the road map.

There are three possible ways forward for this.

* One could create an activity pub event for wrapping an ATP record.
* Lots of complexity for Activity pub clients
* Two wrap activity pub events in a ATP record
* Lots of complexity for ATP clients
* There a bridge that translates between Activity pub events and ATP records
* Impedance mismatch between schemas and identity concepts

All three have real drawbacks and would likely slow progress. Probably better not to put limited time of the dev team in expensive interoperability with activity pub at this time.

I think this is counter to the separation of server from application goal.
If you want to make a new application with different record types you can complete with

To allow per server customization is to introduce vendor lock in to the protocol.

If you want to sell a custom experience make an app with the record schema that you want and let the users pick their servers.

What do you think about Theseus Identities?

Is there part of the portable identity problem you think this works poorly for?

https://youtu.be/Z04RGWgHzvU

Thank you for sharing this, this direction is really great.
Is there a specification for this somewhere public?

Have you happened to have stumbled on KERI by any chance?
I think it fits nicely your notion of Theseus IDs (up to a point) and it might offer some interesting ideas.

It's pretty much a series of "events" that change the state of the identity. (the main ones are "key rotation" and "delegated key rotation")
It uses a notion of a "next key" that the user can use to "rotate" to that key if their current one gets leaked/lost (similar to the "recovery key" mentioned in the video
Has a concept of a "witnesses" that can be used to pull the events for an identity, and to recover a lost "next key".
The idea of ticks doesn't really exist for ordering, but instead the moment two conflicting events are seen, both are considered invalid and the key needs to be rotated using the "next key".
Has some ideas in general def worth taking a look at (ie delegation).

• https://www.youtube.com/watch?v=izNZ20XSXR0
• https://identity.foundation/keri/did_methods/