Lol. Thank god for urban dictionary. xD

When one is so excited about things that they become overwhelmed and are unable to do the very things they are excited about. Like when a puppy plays so much it exhausts itself to the brink of unconsciousness. This kind of overwhelm is often mistaken for anxiety, but it is in fact The Puppy Problem.

I went digging in the history — something like

when someone posts “does anyone like puppies?” then gets a bunch of replies and changes “like” to “kick”

[pioneer] 🇺🇦: Users in ATP have two identifiers. An "identity" and a "handle" (

So yes. Domain names in ATProto are the normal domain names as you currently know and love them.

For the identities ATProto is using the

• Web is just a URL that points to a PDS, so same terms apply as the hostname one.
• Placeholder is based on cryptographic key which makes it unique. You can read more on the
  did-plc docs
  .

my 2 cents about the licence debate:

• dual-licencing (and more) is a thing. AGPL can be used for the RMS-style crowd but another licence more "business-friendly"
• one could release under different licences accross time. Releasing under AGPL first, keeping a more recent version proprietary. Waiting each time next version (or x years) to release under AGPL. The risk is network fragmentation because people using only the AGPL version will be ahead of time (and protocol version)
• the app can be under different licence (proprietary) than the protocol library (more OSI-compliant). Thus, maximizing chances of protocol adoption but keeping some business moat in the app (risk is concurrent app implementation with feature parity, including AGPL community ones but there always be a delay)
• maybe the licence is not the key from the business perspective but the business model should be assured by other constraints. I'm thinking about Signal: the code is FLOSS but, in order to use the official servers, you have to agree to ToS that impose you to use the official client, not any fork.

Hard choice 😓

In reply to

Dean
This is kind of how Facebook does it, which is definitely possible but begs the question if such a feature is within the scope of the protocol as it would change how all atproto client apps are used/perceived compared to just "likes"

(Six degrees of elon musk.)

But seriously social graphs / web of trust for social media is amazing in concept but insanely hard to do. The ux alone has probably never been done right.

That’s before having to separate “i trust x” from “x is who they say they are” from “i wanna hear what x says”.

Could an indexer add additional metadata/labels to posts that could be shown to users of any client?

ie Can an indexer provide to their users that a user/post is “trustworthy”? (For whatever the definition of trustworthy is for that indexer?)

Indexers can even have “trusted” users who would contribute using bespoke clients or just by linking stuff.

An indexer of a university could even have verified experts who vouch for posts. Etc.

Something I’m considering for a side project is to allow users to create trust lists for content, and you could subscribe to said lists. Your company could have one, your school could have one, your borough/city/country, etc.

Your client would basically use those as overlays to annotate the content you see.

Indexers could also play the sane role maybe. Allow clients to subscribe to multiple indexers and decide which labels to show. ie “

whyrusleeping

Note that likes/upboats/downvotes/etc arent “in the protocol”. They are a particular type of interaction defined by a particular lexicon. The downvotes you see in the repo are defined in the app.bsky lexicon, which is a twitter-like system built on the AT protocol. One lexicon including downvotes doesnt mean everything using atproto has downvotes.

This is news to me. I thought atproto clients would share the same standard for accounts/posts.

pfrazee: sorry, I might have misunderstood some things as well, so the question might be just invalid.

The protocol overview over at

As with Web search engines, users are free to select their indexers. Each feed, discovery section, or search interface is integrated into the PDS while being served from a third party service.

From which I've assumed that the user will be able to select one (or more) indexer services that will allow them to discover posts.
I also assumed that the indexers are not full blown PDSes, but rather provider some sort of feed to the clients/PDSes.

How far off the mark am I so far?

It's less pinned down than some of the other parts of the architecture but at a high level.

Separate the tasks of safety labelers and acting on the labels. Let's say you want your clients to filter out content illegal in the EU and put pornography behind a click through prompt. You would subscribe to one data labeler that did illegal in EU labels and one that did porn labels. Then program your PDS to discard any records labeled not for EU and your client to put records labeled porn behind a click through.

This empowers the user to choose the labelers they want to trust. Unlike the big tech platforms where the platform decides what to show, what to tag with context, what to put behind a click through, and want to hide entirely the user picks labelers and actions.

Labelers can compete to provide the most useful labels and clients can compete to provide the most useful actions. For example you could have a labeler for "sports news" I didn't action for "don't show during working hours" this is not something the trust and safety teams at large platforms would spend the time to do but might be content filtering that helps a user get their work done.

There is space in context moderation for much more nuanced and personalized curation than we do now.

If you have good filtering of content that is illegal or offensive to you then you are more free to try out many different timeline ranking algorithms to find ones that bring you joy and value.

whyrusleeping: Mind if I quickly bug you about something gosky specific? :D
I'm grabbing the car from getRepo, and trying to process the various objects that are in there.

1. What's the best way to traverse the car's dag? Tried using go-car/v2/blockstore but going through all the cids in the car is a bit of a slog as they seem to include the car's structure as well.
2. Even better, is there an IPLD lib I could use to traverse this? As even once I found the blocks I'm interested in, I need to be able to find their $type to unmarshal them into the right struct. -- Or is there a better way of doing that by any chance?

If these questions are not making much sense please feel free to just ignore them, I'll give it another shot after reading a bit more about cars. 😂 -- Either way, thank you very much in advance! :D

Edit: Found it, should have pulled more often from main :D
https://github.com/whyrusleeping/gosky/blob/master/repo/repo.go#L69-L77

[pioneer] 🇺🇦: I'm still trying to understand this as well, but my best guess/understanding so far is the following:

1. Assuming you're on the one.social PDS and your friend's is on two.social using the handle friend.two.social.
   When you tell your PDS to follow your friend, the PDS will call the com.atproto.handle method on two.social with your friend's handle, will get their DID and the CID of their repo and can then call com.atproto.sync.{get,update}Repo to get their posts etc.
   When your client then calls your PDS to show posts etc, your friend's posts should be included with the rest.

2. Your friend's DID mentioned above is going to look something like did:plc:vzmlifz3gharxxx, this should be what will allow you to keep following them when they move to a different PDS as it's not tied to a specific PDS or handle. Assumption: It makes sense that when your friend moves, they'll need to add a "moved to a different pds" record to their repo, so people know what happened.

3. No clue :D too early I guess?

I like this answer. I would add that once you follow since that follow is remembered by the DID if the account you are following changes their handle from

If your friend moves PDSs then they can update their DID Document to point to the new PDS so the old PDS does not need to give them permission to move to the next one.

No it is important that you be able to migrate away from your PDS after they disappear without warning.
What you need is a key that you hold and a client that is maintaining a in sync repository.
Then you can just issue the new DID Document on your client and upload your copy of the repo to the new PDS.

Loading the recovery key into your client so you can rotate the account key away from your old PDS may involve scanning a QR code or typing in a long recovery phrase.

If Gmail/Drive went away tomorrow I would lose data. This limits me to using services with very high trust in their durability. This in turn limits me to using services with lots of capital. That is a recipe for oligopoly. By making the migration cheap for the users the failure of a PDS is not so bad and users can take chances on small PDS doing interesting things.

This is where the economics move away from the natural monopoly of any service that is data storage intensive.

AtProto !=

AtProto: A URI scheme and transport protocol for self authenticated data. (Probably should be moved to a standard body at some point)

Bluesky PBLLC: A public benefit limited liability corporation funded to do research, build an example distributed social network, and support the Bluesky community.

Does that help?

Hey ya'll, I'm really interested in this project and I've been pouring over the documentation. It's mostly clicking but I'm still hung up on the specifications regarding the Data Repositories.

The developer guides specify that the Personal Data Repositories will be a specific data structure; a Merkle Search Tree with each node being an IPLD object.

1. I'm wondering what this means for someone trying to implement a server based on the protocol. Do you envision this data structure being the actual back-end storage of user data, or is it a required output when requested? In other words, would developers store data in a traditional database and then compile everything into a PDR file upon request? I'm just trying to wrap my head around the potential implementation details.

2. Are there reference implementations of Merkle Search Trees our in the wild? Didn't find much on them, they seem like a new idea?

3. The PDR looks like the description of a blockchain or some other distributed ledger. Not a critique or question, just an observation :)

Exciting stuff folks, can't wait to see more from the team soon!

1) The repo is technically an exchange format. Like a git repo most git clients store the history in the merkle trees. Since the MST is a deterministic data structure if you store the key value pairs you could generate the tree on demand. No promises you can do that efficiency though. My expectations are that most implementations will store the repo as a conical representation and then build an index over it to make search faster.

You have to store the records. The intermediate nodes are approximately one for 32 records. Likely less than 4% storage blowup to enable tree diff syncing.

3) This depends on what you mean by Blockchain. It is a chain of blocks with hashes to link them together so yeah like git it is a block DAG but the consensus mechanism is to let the PDS put updates in order so it is not in the Bitcoin sense of a Distributed consensus algorithm.

Aaron Goldman: Thanks for the response! This clarifies it for me a bit but I think I need to do a bit more research. Sounds like looking to how Git repositories are implemented might shed some light on how PDRs could be implemented?

You have to store the records. The intermediate nodes are approximately one for 32 records. Likely less than 4% storage blowup to enable tree diff syncing.

I know some of those words!

If you are interested in private shared data in public repositories it is also worth reading about WNFS

https://guide.fission.codes/developers/webnative/file-system-wnfs

Aaron Goldman:

Yeah ... I have a bad habit of using obscure language when common words would do. Please call me out so I can improve my explanations.

Oh, no snark was intended on my end! I appreciate you taking the time to explain. I'm just new to these data structures

I tend to explain in overly complicated ways but I can give it a shot.

If you want an account that can be moved from one server to another you need some kind of ID that you can prove you control. If you do this by making a public key your ID then you can prove you know the private key as proof you control the ID. For example did:key or did:pkh are derived from public keys and can be moved by the user that knows the key.

Bluesky's did:plc takes a middle ground. Where the original key can sign a statement adding a new key or removing an old key. This is technically less portable as someone needs to store the did:plc 's operation log. It is a tradeoff between maximum portability and maximum usefulness.