Hi 🙏🏻

I need bluesky invite code. Thank you if you send it to me.

yes, build atproto

123cd packages/dev-env
vim src/index.ts
node dist/cli.js

"algorithmic choice" turns out to be more complicated than it first seems. Isn't it always.
I think about it in three layers.

Client, PDS, Indexer

The client is the final arbiter of what gets shown to the user. If you don't believe that install an ad blocker. If something is flagged I say violence or sexual should the client put in a label, put in a click through, hide that it was even there? The client should have local rules for hiding and re-ranking at the edge.

PDS desides what goes to the client. The client can't reorder what it doesn't know about. The bulk of the work of personalisation is on the PDS. Does this post deserve to consume your cell phone bandwidth and battery, does it warrant a push notification. To change this behavior you are limited by what the PDS has as options.

Last but most contentious are the choices for what indexes to build. As the network grows most repos will not have anyone on your PDS following that repo. But we wanted a large world network. The PDS can build indexes over the repos it follows but will also need to query an Indexer. The Indexers are following all the repos they can. Building large but generic indexes. The PDSs are limited to the queries that are efficient given the way the Indexers sort the data.

In the end the client is very personal but has minimal scope for ranking. The PDS has lots of bandwidth, processing, and power but need to limit what you can do to not interfere with the other users. The Indexers have no personal behavior reading and sorting everything in the hope they have the indexes PDSs want to build their algorithms on.

hi, update done

• add login, signin
  https://bsky.syui.cf

Good morning. I've been reading through the spec and am trying to write a small lexicon parser, but I'm seeing some differences between the lexicon documentation and the lexicons.

The main thing is that the lexicon structure includes top level elements like parameters, input, output, etc. that are nested inside of {"defs": { "main": {} } }. That behavior is described in the lexicon documentation.

Can anyone shed some light on this?

Sure, let's take this typescript code from the schema documentation on the lexicon page:

1234 type: 'query' | 'procedure' | 'record' | 'token'
  // if type == record
  key?: string
  record?: JSONSchema

That would lead me to expect those top level elements, key and record, to either be present (or not) inside of record type structures. Given the type attribute isn't marked as optional (no question mark), I also expect it to be present.

Ok, one more thing that doesn't seem clear.

The https://atproto.com/lexicons/com-atproto-handle#comatprotohandleresolve lexicon has the parameters attribute and it doesn't seem to line up with the lexicon schema.

123456789101112    "main": {
      "type": "query",
      "description": "Provides the DID of a repo.",
      "parameters": {
        "type": "params",
        "properties": {
          "handle": {
            "type": "string",
            "description": "The handle to resolve. If not supplied, will resolve the host's own handle."
          }
        }
      }

Where the lexicon schema looks like this:

123456interface LexXrpcQuery extends LexUserType {
  type = 'query'
  parameters?: Record<string, LexPrimitive>
  output?: LexXrpcBody
  errors?: LexXrpcError[]
}

Is that a typo?

On the Lexicon guide at https://atproto.com/guides/lexicon#rpc-methods, it looks like there is a more accurate view of what that properties structure would look like:

123456      "properties": {
        "did": {"type": "string"},
        "name": {"type": "string"},
        "displayName": {"type": "string", "maxLength": 64},
        "description": {"type": "string", "maxLength": 256}
      }

So different servers will host the data…
But can I run my server that will host all the data related to my client stuffs ?
And talk to that server by default in my client ?

Also, can an already existing social media move to atproto and still conserve its business logic ?

Atp’s selling point is to allow users to move between clients and repositories and interact with users from other repos. If you don’t want that functionality I think you’d be better off with a more straightforward backend for your app. (This is my personal opinion which might not be shared with others or atp devs)

As for your second question; Atproto allows you to define your own types in order to extend the existing functionality. Other clients can then add support for those types. That should in theory allow you to match the functionality of an existing social media. Think of them as nostr nips since you seem to be familiar with nostr. Not all clients implement all nips.

I don’t know if a kind of premium subscription is possible in atproto…

I don’t understand well the concept that’s why I am asking
For example a premium feature to add more stuffs like traditional social media

I like to use the analogy of a podcast.
RSS is an open protocol.
Any podcast app can pull from any server.
Any server can serve any podcast app.
So do you need a server to make a podcast app? No but many will whether it's just for updates or for features like syncing which podcast you listen to.

You're the client developer is separate from the podcast host.

At protocol takes this one step further. There are three parties. The app developer. The content controller. And the personal data server.

The app developer doesn't need a server anymore than the podcast app developer did but they may want to for their own features.
The PDS personal data server just stores in the repo whatever the content controller wants them to. This could be like producing a podcast or simply rating one.

The content controller, identified by a DID, uses the applications to create content and adds that content to the repo they control.

We have transitioned from a two-party web for one party is the server and the other is the client to a three-party web where we have server, client, and content creator.
Once I have a PDS I could use many apps but those apps don't own my data My data lives in my repository not my applications database. The PDS is serving my data but it is not the PDS's data I can move my data to a new PDS whenever I want.

Web2: client, server
Web3: client, controller, server

The server is still required and most users will want to keep a copy of their data in case their PDS disappeared suddenly but you no longer have to be able to run infrastructure to be a publisher or an app developer just a PDS operator.

I don't know if that made things clearer or more confusing let me know if I inspired any questions.

nngerakines: there are three ways to do a recovery key that makes sense to me. (Not necessarily atproto)

1: hardware TPM has a non-extractible key. You must have the hardware to use the key. Examples Yubikey (FiDo key), phone, laptop.

2: Long strong seed words. Example https://www.eff.org/dice EFF's Short Wordlist #2 [.txt] has 1296 words that is 10.3 bits of entropy per word. 25 words is 258.4 bit so plenty for a 256 bit key. Just use sha256 or whatever to hash to a 256 bit key.

3: Salted Slowed key derivation. Pick a random 256 bit public salt and a slow key derivation function like PBKDF2, bcrypt or scrypt. Use the public salt and your seed words to generate the secret key. Store in your DID Document both the public key and the public salt. When you need to regenerate the recovery_key pull the DID Document find your seed words and regenerate the key.
Since this process is slow and individualized, we need far less entropy in the seed words. Most of the entropy is provided by the public salt. 6-8 word from EFF's Short Wordlist #2 would be sufficient for your seed words giving you 62-82.7 bits.

60-80 bits would not have been enough if we were using a fast hash and no salt as someone could generate billons of billons of keys hoping to find a valuable one but it plenty of entropy if they have to attack your specific public salt by running a slow function billons of billons of times.

So hardware TPM, 25 seed words fast hash, or 6 seed words + 256 bit public salt slow hash would be how I would store the recovery key.

Specifically I would use a physical piece of paper with the did:plc:ex234 and the 6 seed words printed on it and the public salt in the DID Document next to the recovery key. e.g. did:key:z6MknqfvFLUGULzfP2KSV1mquSzfkUZizuPefmePx5xRVi9X#recovery_key_4b503e0cb36927afec3b9081d518fb9007be35dfe327dd904b7c21d43471c07f

How do you do the domain name handle?

123{
  "did": "did:plc:uqzpqmrjnptsxezjx4xuh2mn"
}

Not sure whether I understand the question. The repo's are authenticated data so you can validate them no matter how you got them. If a client had nearby or airdrop you should be able to gossip around the repo's.

Granted the demo client in beta now doesn't support local network connections it bounces everything off the PDS. You would need a client that held an account locally rather than server side signing.