If they pretend they never heard of it two cases. One, from the beginning e.g. your doc is >4k so the directory rejects you. You can hand your delta to various PDSs so they can try submitting it and condense themselves that the directory is malicious. Two, they changed the history. You notify PDSs of the DIDs whose history have changed they pull them from the directory compare to local copy of log convince themselves the directory is malicious.

For "created with different keys" no the did:plc:<sha256(initial state)> means that a different set of keys will have a different hash. The only way to do this is to break sha256 and then a better use would be to win all the Bitcoin mining with that math instead of stealing a did:plc

Hi Bluesky devs,

I'm interested in using the protocol as a tamper-proof means of publishing of data. My current way of doing this to a Git commit: first, I PGP-sign the commit, and I then persist the hash representing the commit to https://opentimestamps.org/ (along the line of NIP-03 in Nostr). I suppose the problem with this approach is that the identity tied to the Git commit and PGP key is not self-sovereign (an email address). And that using Git, PGP, and publishing the repo via BitTorrent/IPFS would require some technical expertise.

As such, my use case is more on the authenticated data part, where the social network part is not essential (or maybe it could be used for the trust network). What would be the easiest way to use the protocol for this use case? I have looked at an

It works for me if I did make run-dev-env. I was able to ping the local PDS server. Sorry that I can't be of help, because I'm also new.

1234567891011121314
██████╗
██╔═══██╗
██║██╗██║
██║██║██║
╚█║████╔╝
 ╚╝╚═══╝  protocol

[  v0.1.0  | created by Bluesky ]

Initializing...
[2582] 👤 DID Placeholder server started http://localhost:2582
[2583] 🌞 Personal Data server started http://localhost:2583
Test environment generated.

123456789{
    "sig": "v0Oilmbj4DmrKl8updN4a4RRy-W4KMkFbQgzeic5wWwIUNcv2MubGAcIcWorHO7ENfVMw277vsZ_8ElTLwyGww",
    "prev": null,
    "type": "create",
    "handle": "aarondgoldman.bsky.social",
    "service": "https://bsky.social",
    "signingKey": "did:key:zQ3shP5TBe1sQfSttXty15FAEHV1DZgcxRZNxvEWnPfLFwLxJ",
    "recoveryKey": "did:key:zQ3shhCGUqDKjStzuDxPkTxN6ujddP4RkEKJJouJGRRkaLGbg"
 }

is the initial state

123456789101112131415161718192021  {
    "sig": "-HaOHhXggXNikMIh1gVY6mLcPgkroO9Q3l3wScUX2FQd1Z4Fp8OdOO4KYO5ZQJzF0aCDd1pKbVojCZJxTqCT8A",
    "prev": "bafyreie3v6g2tzcz5pjvvaoeygemqnvcmhr2q64pztthmgngab7gzspadq",
    "type": "plc_operation",
    "services": {
      "atproto_pds": {
        "type": "AtprotoPersonalDataServer",
        "endpoint": "https://bsky.social"
      }
    },
    "alsoKnownAs": [
      "at://aarondgoldman.bsky.social"
    ],
    "rotationKeys": [
      "did:key:zQ3shhCGUqDKjStzuDxPkTxN6ujddP4RkEKJJouJGRRkaLGbg",
      "did:key:zQ3shpKnbdPx3g3CmPf5cRVTPe1HtSwVn5ish3wSnDPQCbLJK"
    ],
    "verificationMethods": {
      "atproto": "did:key:zQ3shXjHeiBuRCKmM36cuYnm7YEMzhGnCmCyW92sRJ9pribSF"
    }
  }

is the first delta

In my mind there are three non-malicious reasons for the directory to reject a delta.

• It is not signed correctly.
• It dose not have the latest delta as it's prev CID.
• It is too large or exceeded the rate limit.

I have a question for the bsky/atproto devs. How do you imagine 3rd parties to develop apps? We would definitely work out a set of lexicons, generate the stubs and implement the business logic. But where is that code going to live? As a PDS?

The docs recommend providing the base atproto functionality along side new features (and a lot of it is needed/useful — auth and repo usage), but are we expected to build inside of the indigo/atproto repos? That doesnt seem very scalable.

Is there a dev guide in the works? I have a couple of apps in progress, but Im not sure the appropriate place for them to run. Currently, Im just dumping them in the api/pds subdirs for indigo.

For apps that the PDS has no application specific logic for the application would need to submit the set of paths and record that the application wanted to be included in the repo to the PDS for signing.
One could imagen a UI from the PDS to the repo controller
"""
Application xyz is trying to insert records to collection abc and def

• Allow once
• Allow for 2 weeks
• Allow indefinitely
• view records and approve individually
  """

Weather the repo additions and commit signing happens on the PDS or in the repo controller's client there will need to be UI for granting any particular application the ability to insert into the repo.

An alternative architecture that was considered was to issue capabilities to aplication so they could sign the repos themselves but that would mean every client would need to do validation work to check that any given commit only changed the collections that the capabilities allowed them to. Probably better for them to propose a new commit and the validation only need to happen before the PDS or client signs the commit to make it the new head of the repo.

I think it would make more sense to keep record signing and repo mutations on the PDS side. That would cut down on code duplication, and the client code would stay more lightweight.

But how would you feel about separating the atproto and bsky apis? Since they are currently built/deployed together, there is not a clear barrier for integration. Separating these components would provide outside teams a better picture of where we hook into the systems. This would also serve as very thorough example application for the atproto protocol/network.

Maybe this is orthogonal, but offline first authoring is definitely missing from most current solutions (DWNs will probably strive for that), and maybe it can be done without signing, by constructing the MST locally and submitting it to the server as a patch?

Anyways, we should do almost everything like Git until proven there is something that needs change, because it worked well so far.

I was trying to figure out a way to write clients where you can pull in any lexicon that you want and came up with something like this

123456789101112131415161718192021222324252627282930export class XRPCClient {
  procedure() {}
}

export class Lexicon {
  constructor(readonly client: XRPCClient) {}
}

export class AtProtoLexicon extends Lexicon {
  readonly server = new AtProtoServerLexicon(client);
}

export class AtProtoServerLexicon extends Lexicon {
  createSession() {
    return client.procedure();
  }
}

export class BskyLexicon extends Lexicon {}

export class GraphiteClient extends XRPCClient {
  readonly atproto = new AtProtoLexicon(this);
  readonly bsky = new BskyLexicon(this);
  // example:
  // readonly bitcoin = new BitcoinLexicon(this);
}

const client = new GraphiteClient();

client.atproto.server.createSession();

for xrpc lexicons i think you can do something like

123456789101112131415161718const res1 = await agent.com.atproto.repo.createRecord(
  {
    did: alice.did,
    collection: 'app.bsky.feed.post',
    record: {
      $type: 'app.bsky.feed.post',
      text: 'Hello, world!',
      createdAt: new Date().toISOString()
    }
  }
)
const res2 = await agent.com.atproto.repo.listRecords({repo: alice.did, collection: 'app.bsky.feed.post'})

const res3 = await agent.app.bsky.feed.post.create({repo: alice.did}, {
  text: 'Hello, world!',
  createdAt: new Date().toISOString()
})
const res4 = await agent.app.bsky.feed.post.list({repo: alice.did})

(copy pasted from github)

I wonder if its possible to not even use a code generator for lexicon schemas

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748interface Schema {
  properties: { [key: string]: Property };
  required: (keyof Schema["properties"])[];
}

interface Property {
  type: keyof PropertyType;
}

type PropertyType = {
  string: string;
  boolean: boolean;
  number: number;
};

type OptionalProperties<T extends Schema> = Partial<{
  [key in keyof T["properties"]]: PropertyType[T["properties"][key]["type"]];
}>;

type RequiredProperties<T extends Schema> = {
  [key in Extract<
    keyof T["properties"],
    T["required"][number]
  >]: PropertyType[T["properties"][key]["type"]];
};

type SchemaFunction<T extends Schema> = (
  args: OptionalProperties<T> & RequiredProperties<T>
) => void;

function createFunction<T extends Schema>(): SchemaFunction<T> {
  return (args) => {
    console.log(args);
  };
}

interface Thingy {
  properties: {
    foo: { type: "string" };
    bar: { type: "boolean" };
    baz: { type: "number" };
  };
  required: ["bar"];
}

const myFunction = createFunction<Thingy>();

myFunction({})

ChatGPT came up with this, but if you use intellisense on the function that gets created it just makes a whole function out of thin air that matches the simplified schema O_O

Wondering about how to create a DID for the custom algorithm. Do we use our own account’s DID or do we make an API call to create one first? The did:web is provided but I may want to use did:plc

Is it possible to change the DID after publishing the custom feed?

and even extracting the block list for a user can take up to 80 seconds (!) if the account is following a lot of users.

This is straight up wrong, you can download an entire repo in mere seconds, even for the largest repos in the whole network

There’s two majors differences/ benefits of AT over AP

You'll be able to port your account between servers including content.
The way the data is structured you don’t have to fear losing all of your data in the event an instance doesn’t give you enough time to migrate your account. This happens often with Mastodon

Custom algorithms. You'll be able to choose what algorithm you use.

I know I'll be running my own PDS as soon as federation is on. (Actually I'd probably stand one up before that if there were docs.)

Not pushing for a timeline at all because I know that's not how software dev works, but do you have any insight into how far along federation is?

The only insight into the federation protocol is to point you at some reading.

https://youtu.be/gbqDgsfeiac

https://youtu.be/UeSb7vC0K7Y

https://github.com/fission-codes/spec/blob/main/car-pool/car-mirror/SPEC.md

There are at least three problems to think about.

• Know if a repo I follow has an update?
• Sync a repo when you have an old version of that repo.
• Firehose of all blocks from all repos that have this PDS as a host.

The first two can be done agents any PDS with a cache of the repo. The last is PDS specific but indexers really want to ask the question. "Give me everything that has happened since the last time I talked to you."
getAll(since="2023-05-28T21:31:21.157010")
getRepoHeads(since="2023-05-28T21:31:21.157010")
syncRepo(did="did:plc:toxy3kpelhv5gwubytayrsbw", since="bafyreic4iq5quhattt5ghdidl6smeqmrknfal4mdggvjtrvefivggzucjm")

car-mirror is not the federation protocal but the need for a federation protocal is to be able to mirror a car file as the repo is just a car file with the blocks of the repo.

That is a little hard to answer. We need to store the n bytes that is the user content. There is nothing we can do about that. I addition to the raw data there is the intermediate blocks from the Merkel tree. It is a mostly balanced tree with a fanout of 32 so most of the nodes are the leaves with about 1/32 < .04 blowup in size for the first layer of inodes. The second layer is 1/(32^2) < .001 blowup. The root is signed so about 64 bytes per commit for the signature. On average the Merkel tree + signature will use less space than signing each record with its own 64 byte signature.
My general rule of thumb is that for the amount of data being stored expect a 4% size blowup for the repo over the raw data in the repo.

If the repo is posts 1 kiB per post is a reasonable guess. For images 1-10MiB. For video 1-3 GiB per hour.

Now for the Wild guessing part.
Most users will upload less than an hour of video a week, let's call it 2.5 GB. That is enough to totally dominate the text and photo data.
If you have 2,000 user on your PDS that average 2.5 GB/week you would get something like 5 TB / week. Fortunately, most of your users are using much less than that. https://www.amazon.com/dp/B08V13TGP4/ a simgle drive could hold 1,000 hours of video

So a repo controller certainly can delete content. The PDS can then garbage collect at its convenience.

But if they don't delete anything the PDS needs to keep it around as it is the content host of last resort.

That said offloading unpopular content to a glacier/tape store like store could help a lot.

Yup

https://github.com/bluesky-social/atproto/blob/main/packages/repo/src/mst/util.ts#L8