Oh, you should look at Nash Equilibrium.
It is a cool way to think about making seditions in the presence of other people's decisions.

https://youtu.be/0i7p9DNvtjk

e.g. I thought holding your own keys is important to empower the users. Also, adoption needs a fast way to get started so we need a PDS to be able to generate the keys and manage them for you.

This is what lead to the design for did:plc: fast easy entry but the ability to take responsibility for your repo.

The hope is that rather than too many invites to the

Having more than a third of the users on a single company's servers is a big risk to the project.

That’s my point.

They don’t want more people on

When watching events from com.atproto.sync.subscribeRepos - is there a way to get a subject of a deleted like or follow?

I understand that app.bsky.feed.like records get deleted, but the subjects themselves still exist.

I basically need an answer to the question "Is this repoOp deletes a like for from the post X"?

does it have to? i would envision one handle dynamically resolving to multiple DIDs

though the conflict would still arise if i was expecting to always get the same DID

in the nth, how it different to changing the handle pointer to a new DID every 10 seconds?

E.g. one might be my public social media account. The other one is my account in a specific, isolated*, community.

• not a single instance. But maybe a federation of 4 pds instances. Compare it for example with the current sandbox situation.

Ok, I think found an option. Probably not optimal, but at least something.

I should be able to get a previous commit from com.atproto.sync.getRecord. E.g. something like this:

123456        const result = await agent.api.com.atproto.sync.getRecord({
          did: evt.repo,
          collection: ids.AppBskyFeedLike,
          rkey: rkey,
          commit: evt.prev?.toString(), // Delete event has previous commit
        })

cnames can’t resolve to txt records. they can only resolve A and AAA records. some dns servers will allow cnames to point to cnames but not all. a cname also can’t be assigned to @ (root) which is why alias exists.

not sure why they won’t allow _ as it is a standard for txt records and auto discovery. it would be invalid for an A, MX, or CNAME to start with an underscore though, so maybe they were just being lazy and blocking it all together lol

not sure why they won’t allow _ as it is a standard for txt records and auto discovery. it would be invalid for an A, MX, or CNAME to start with an underscore though, so maybe they were just being lazy and blocking it all together lol

I've been contacting freedns admin about "_" char in txt record, hope we'll get an answer

I found this and I think it's not possible to set header as application/json on github pages

https://stackoverflow.com/questions/48283075/githubpages-how-to-enforce-custom-content-type-type-for-any-file

I have a strange situation where my handle I used to sign up with on my own instance didn't setup correctly and kept saying "Profile not found" and "Actor not found"
So I looked around and found I configured DNS without a wildcard. So I did that wiped the database and tried to register again

This time it kept giving 400 saying it couldn't create a did:plc
I used a different handle and it worked. I changed my handle and now it is busted.

• I can post, but it posts under the previous handle
• The interface shows my profile fine using the handle I signed up with
• The interface in settings shows my handle is the one I changed to
• Loading the profile using the one I changed to fails to find the profile

Any ideas?

Not exactly being trolled

https://github.com/bluesky-social/atproto/tree/8de64178c07b07ffcdaf25ae5afa78831168d02f/packages/pds/src/api/com/atproto/sync

The sync API is there today.
You can use getHead to regularly pull the heads of the repos your users follow and getRepo to get the set of IPFS blocks that are in the current repo but not the head you are on.

getHead and getRepo are all you need to start pulling from a PDS.

The part that is missing is having them pull the repos hosted by your PDS.

Depends on how you think about it. The MST is an imitable data structure that is pointed to by a commit. All immutable data is a CRDT as no divergence can happen if nothing changes.

But that's silly clearly we mean what is pointed to by a mutable at: URL. So we consider the commits. Each commit is signed and points to a previous. So if one is an ancestor of the other the merge is a fast forward. What if we have a fork? We could do a first or last writer wins and then we are back to a CRDT but what we do is that a commit is only a candidate head. The PDS it can do a compare and swap. The PDS will only do a fast forward merge where the new commit has the current Head as an ancestor. Now that commit is the new current Head. Otherwise it just rejects you and tells your client to rebase its changes.
So in that sense it's not a CRDT since if you only have the commits you can't tell which is the Head you must talk to the PDS.

In an earlier design the pds responded not with a https authenticated json to tell you the Head but with a signed Json. Back when that was true you could store the signed head assertion, called a tick, and by taking the tick with the highest timestamp know what the head was which then made it a CRDT.

So the thing that makes it no longer a CRDS but instead web service state is that the ticks are no longer signed to force you to use the PDS to get the Head every time.

moving to be less git and more Subversion
Purge requests are hard.

If a repo has two candidate heads, I can follow both prev headers back to a common ancestor so I can then tell the difference between A added and B removed when A has a record and B does not. This means you don't need to carry around tombstones.
This is useful in a distributed change control system like you would have if you kept the repo signing keys on your user agents and didn't trust your PDS with the right or ability to update your repos.

If instead you trust the PDS then you can do all updates in a central place avoiding forks and has a straight-line fast forward. You can buy more performance by giving up some decentralization.

Removing 'prev' is much more interesting change than adding the timestamp.
Adding a timestamp is just shortcut for which block you have.

Actually here for what seems like a similar reason, registering on the pds seems to go well "pds:db","handle":"XXX","email":"XXX","did":"did:plc:cd5la5x34urgndl5pv3vl3wq","msg":"registered user"

Followed by a atproto.server.createAccount request "pds","req":{"id":5,"method":"POST","url":"/xrpc/com.atproto.server.createAccount","query":{},"params":{},"headers":{"host":"XXX","user-agent":"XXX":"*/*","accept-encoding":"gzip, deflate, br","accept-language":"en-US,en;q=0.5","content-type":"application/json","dnt":"1","origin":"https://bsky.app","referer":"https://bsky.app/","sec-fetch-dest":"empty","sec-fetch-mode":"cors","sec-fetch-site":"cross-site","te":"trailers","x-forwarded-for":"XXX","x-forwarded-host":"XXX","x-forwarded-proto":"https"}},"res":{"statusCode":200,"headers":{"x-powered-by":"Express","access-control-allow-origin":"*","content-type":"application/json; charset=utf-8","content-length":"615","etag":"W/\"267-PrTSvVegUJfRfdAbRSKN6grv4r0\""}},"responseTime":763,"msg":"request completed"}

But after that it keeps failing to fetch the created profile "xrpc-server","err":{"type":"XRPCError","message":"Profile not found","stack":"Error: Profile not found\n at ServiceClient.call (/app/node_modules/@atproto/xrpc/src/client.ts:126:15)\n at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n at handler (/app/node_modules/@atproto/pds/src/api/app/bsky/proxied.ts:9:19)\n at <anonymous> (/app/node_modules/@atproto/xrpc-server/src/server.ts:207:35)","status":400,"error":"InvalidRequest","success":false},"msg":"unhandled exception in xrpc method app.bsky.actor.getProfile"}

Not sure if I missed something during setup? Only started poking with this recently. I'm running on k8s but the setup is very similar the the docker compose file, just a caddy container forwarding requests to the pds container. On_demand_tls also works. Using the default plc, view, view_did and crawlers url's

network extender

... i think? I haven't seen that in ages

That your phone is connected to a tower that is not vetted by your cellular carrier. Most towers are either your carrier or roaming on a carrier that has a contract with your carrier. But some places don't have good coverage and so run towers or network extenders that back hall using the Internet back to your carrier. You get free coverage (free for the carrier the carrier will probably still charge you) but less privacy as you are leaking some information from what the network extender can tell about you by monitoring the encrypted stream between you and the carrier.

E.g. using the size and frequency of encrypted voice packets to run voice to text on the entropy fluctuation over time.

So, for something like

12345import { BskyAgent } from '@atproto/api'

const agent = new BskyAgent({service: 'https://example.com'})

const res2 = await agent.com.atproto.repo.listRecords({repo: alice.did, collection: 'app.bsky.feed.post'})

What do you see when you print the res2?

I tried all of this before thus far. Now, this is what I get from this function:

1234567891011121314151617181920212223242526272829303132XRPCResponse {
  data: {
    notifications: [
      [Object], [Object], [Object], [Object],
      [Object], [Object], [Object], [Object],
      [Object], [Object], [Object], [Object],
      [Object], [Object], [Object], [Object],
      [Object], [Object], [Object], [Object],
      [Object], [Object], [Object], [Object],
      [Object], [Object], [Object], [Object],
      [Object], [Object], [Object], [Object],
      [Object], [Object], [Object], [Object],
      [Object], [Object], [Object], [Object],
      [Object], [Object], [Object], [Object],
      [Object], [Object], [Object], [Object],
      [Object], [Object]
    ],
    cursor: '1692888369062::bafyreielghmqwadhnpr3cwnrruynun6d4ovrpvr2nbofwzjcwljabsht6y'
  },
  headers: {
    'access-control-allow-origin': '*',
    connection: 'keep-alive',
    'content-encoding': 'gzip',
    'content-type': 'application/json; charset=utf-8',
    date: 'Sun, 27 Aug 2023 22:01:32 GMT',
    etag: 'W/"f2d0-K08VbFclpc16V0tXtE5dEwdTHZs"',
    'transfer-encoding': 'chunked',
    vary: 'Accept-Encoding',
    'x-powered-by': 'Express'
  },
  success: true
}

To do what?

You could search the content doing something like
https://blue.amazingca.dev/

You could run your own node.
You could try to get an invite to someone else's node

Hi everyone! This is Emily, from the Bluesky team. Now that both the network and the atproto dev community have grown significantly, we’ve been having more multi-threaded discussions over on GitHub and haven’t been able to maintain this Matrix room as much, but really appreciate all the discussions happening here.

As a result, we’re streamlining discussions in the atproto GitHub repo. This room will continue to exist here, thanks to the Matrix team, who very generously offered to take over admin roles here. The room description will be updated accordingly to indicate that it’s no longer an official Bluesky space.

Find us on GitHub discussions here: https://github.com/bluesky-social/atproto/discussions

If you’re a developer still waiting for an invite, fill out the dev waitlist and you should receive a code within a week: https://atproto.com/blog/call-for-developers

no, we appreciate it when people chime in to ask & answer questions! :)

we’ve just found that github discussions has made it much easier for us to: have multiple conversations at once, keep our answers discoverable even as time passes, and have public conversations that we can later link to.

In reply to

EEmily

Hi everyone! This is Emily, from the Bluesky team. Now that both the network and the atproto dev community have grown significantly, we’ve been having more multi-threaded discussions over on GitHub and haven’t been able to maintain this Matrix room as much, but really appreciate all the discussions happening here.

As a result, we’re streamlining discussions in the atproto GitHub repo. This room will continue to exist here, thanks to the Matrix team, who very generously offered to take over admin roles here. The room description will be updated accordingly to indicate that it’s no longer an official Bluesky space.

Find us on GitHub discussions here: https://github.com/bluesky-social/atproto/discussions

If you’re a developer still waiting for an invite, fill out the dev waitlist and you should receive a code within a week: https://atproto.com/blog/call-for-developers

In reply to

As a result, we’re streamlining discussions in the atproto GitHub repo. This room will continue to exist here, thanks to the Matrix team, who very generously offered to take over admin roles here. The room description will be updated accordingly to indicate that it’s no longer an official Bluesky space.
Find us on GitHub discussions here: https://github.com/bluesky-social/atproto/discussions
If you’re a developer still waiting for an invite, fill out the dev waitlist and you should receive a code within a week: https://atproto.com/blog/call-for-developers

I wasn't aware that this was ever an official Bluesky-affiliated space to begin with. 🤔