The acid test for any two competing socioeconomic systems is which side needs to build a wall to keep people from escaping? That’s the bad one!

@elonmusk https://nitter.lacontrevoie.fr/elonmusk/status/1533616384747442176

I have two questions/thought on the DID placeholder and I'm wondering if folks here could share a bit of insight.

1. Has there been discussion around how a user could be logged in to two different servers at the same time? For example a book club with a few friends and a general purpose micro-blogging service? It would be nice to have a single identity use two different networks and lexicons without having to "transfer" the account back and forth. Could the DID simply list several servers? I can imagine keeping records in sync might get tricky?

2. Is there a distributed ledger out there that might replace the DID:plc server? IOTA looks like it also has a DID implementation that looks like it could work: https://wiki.iota.org/identity.rs/concepts/decentralized_identifiers/overview/

I'm loving everything I've read about this project so far and I think I'm going to try and implement a server in Rust if I find free time 😃

If two different servers support two different lexicons that create two different social experiences I'd like to be able to log in and use both seamlessly with a single account, especially if they have overlap in the lexicons they support. For example:

Server A: BlueSky lexicon
Server B: Bluesky Lexicon + Book Club lexicon (5 star reviews, ISBN... stuff?)

They would have two different client apps, but it would be nice to have one account that uses both? When I log in to book club I interact with book club feeds throught that client, but then I swap over to bluesky app and do micro-blogging with that community.

I just feel like there might be a use case for existing in two virtual communities as the same person.

The promise the PLC server makes is that it will return the complete operation log that it has including a timestamp operation at the end singed by the PLC server.

• If it ever returns a shorter log then one it returned earlier with a later timestamp
  then the requester has prof of duplicity.
• If it ever returns a log without the earlier as a prefix with a later timestamp
  then the requester has prof of duplicity.
• If it refuses to sign updates the DID controller can hand out the document mutation operation to PDSs. When they submit the mutation, request the log and don't see the update
  then the PDS has prof of duplicity.
• If the PLC server fails completely this will be obvious. The open source project, or a fork of it, would need to add code that said all timestamp operations before the failure must be signed by old_key and all the timestamp operations after the failure must be signed by new_key. Since every PDS should be storing a copy of the operations log they can upload the log to the new PLC server and get a timestamp operation signed by the new server. After that they could make document mutation operations again as they are on the new PLC server.

It is on the open source project to keep a list of PLC servers and the TID ranges that the are allowed to sign. This is probably how the transition from a PLC server run by Bluesky PBLLC will be transferred to a Raft/Paxos like consortium of PLC servers run by different organizations but also the threat that should keep any organization running the PLC server honest.

The main question is wether we want to allow a tombstone timestamp operation signed by the PLC server that says I have banned this PLC and refuse to take any future updates from it.

I think it is worth being skeptical of the long-term identity mechanism being coupled/controlled by a specific PDS server provider (in this case bluesky PBLLC). The claimed benefit of the identity mechanism is an independent account migration path; if the provider themself controls the migration mechanism that is a problem. the concern you mention (artificial update throttling) is a possibility, and there are a bunch of other bad behaviors possible

The trust required in the short term is that bluesky will actually find a neutral party to run the PLC service (I think of letsencrypt as a role model). The need for this trust is hedged by:

1. the technical details of did:plc which would enable the ecosystem to do a disruptive hard fork away from a single bluesky PLC service on their own (in the hypothetical case of bluesky going sour and not following through on migration, others could start an alternative PLC service copying most existing identities over);
2. tech details of did:plc making it relatively easy for third parties to detect and prove bad behavior on the part of a PLC service provider;
3. the use of DID as a format at all, providing a clear evolution path for the protocol/ecosystem away from PLC specifically (aka, if PLC ends up being a bad idea, ecosystem can still keep the rest of the atproto tech; eg time spend developing clients wouldn't be wasted)
   a nice-to-have 4) would be early support for a handful of specific alternative DID mechanisms; that is a prioritization question and seems reasonable to punt on

What's wrong with this request? Used to work a few weeks ago:
GET http://localhost:2583/xrpc/app.bsky.feed.getTimeline?limit=1&before=2022-12-20T21:34:54.359Z`

Now getting Error: Malformed cursor

The onboarding problem is almost never about the tech. It is about bootstrapping the network. I will jump through hoops to get to a network that has my friends and information I care deeply about but the network starts empty.

So why does account portability help? It helps with small communities of value. Lets say there was a conference that used a atproto PDS and the

Who's bourdon is it to preserve the conversations from the event? The organizers don't have to maintain a PDS for all time to keep the conversations anyone that wants to could pin the content. It is all signed and all in repositories. Just crawl the content and keep a CAR file. You can decide to serve the data later it will all still be valid.

Sorry if my last questions were dumb. Still trying to figure out "small communities of value" qua ephemeral networks, and why they are good/desirable, and also, why people would choose them.

One other thing: in a scheme which focuses on this decoupling of identity from a particular network, I feel like there will be natural inclination to leverage this feature/aspect around things like moderation and user curation, such that there are public blacklists/whitelists of accounts to combat things like the future horde of chatgpt bots and such. And that seems great/needed, but won't the inevitable false positives in these lists/filters be extra disastrous for a given individual? Suddenly, their whole identity will be person non grata, and there wont be any single place to appeal. One day, they are filtered from the public on bluesky, but also find they can't log into their family's group chat, or their university's network. The greater they have relied on the portability of their account, the more different appeals they have to make and fires they have to put out.

We see already today how ruinous it can be to be flagged by some Google bot and suddenly lose access forever to documents you stored in drive. Wont this spec encourage a world where these problems are greater and even more impersonal? I understand, by design, ATP itself cant deal with with these problems other than dividing "speech" and "reach" layers, and making it possible in principle to control your own moderation/filters. But in practice, surely most people will just rely on the filters and the moderation they are given with the service they choose, whether bluesky or something else, right? The character of the problem of being "locked out", blacklisted, etc, wont be really different than today, or will it?

so i've been kinda reading the identity "guide" in the

i'm also not really clear on the entire DID -> DID document resolution process either; is this like DHT-based or something? how do you know which server to ask the DID document from?

I think the best analogy is certificates stapling. A PDS will want to return a signed statement from identity server in the last say 300 seconds. The PDS needs to call the identity server but can send that same cached statement with responses after that.

https://knowledge.digicert.com/quovadis/ssl-certificates/ssl-general-topics/what-is-ocsp-stapling.html

For your case of having migrated the old PDS will either give you the new document pointing you to the new PDS or a stale document. If the stale document is old enough your client will go ask the identity server for itself and see the new PDS.

I have a kind of high level question regarding the Lexicons. Assuming the protocol catches on and people start developing new Lexicons for specific use cases, has there been much discussion on how different Lexicons should reference or depend on each other?

For example, if I wanted to make a GoodReads competitor, and I wanted to leverage the current BlueSky lexicon (getting feeds, graphs, etc) how would one go about adding new functionality like 5 star book reviews and book collections? Some would be independent of the BlueSky lexicon, but reviews and reading updates could be something returned in a BlueSky actor's timeline as well.

Is there a way to specify that lexicons are dependent on each other? Like, if you implement A, you must also implement B?

I'm really looking forward to reading about how you're tackling federation, especially how it compares to ActivityPub!

I'm curious, do people think there is room for both protocols? I could imagine a server being compatible with both... But would it be worth it?

"if possible it'd be cool to have it so that applications can tailor the user's content sources per their own algorithms, and the protocol just serves whatever subset the application asks for."

THIS. So very much this.

I had intended to stay a lurker here but this concept is so very important for any social media platform to be better than everything else out there to date. I thought tiktok had figured it out but technically the following tab is algorithmic (just less intrusive about being so on the followed tab.)

There is a reason that algorithms have worked with Twitter and Facebook and anything that has grown. At the same time there are a number of us that want to see chronological from time to time. But chronological can be too much of a fire hose of information. I remember early days of social media and then the loss of google reader where "the fire hose of information" was a more common discussion. It's why chronological doesn't take off as well for the masses.

Being able to have BOTH chronological and algorithmic and then also a choice, whether via different interfaces or an easy to access toggle or tab would be a game changer. I very much want this to be the new way developers think about social media. Choice. Options.

Just wanted to get in and emphasize allowing that particular flexibility. 😎

https://blueskyweb.org/blog/2-7-2022-overview#:~:text=Our%20board%20members%20include%20Jack%20Dorsey

"board members include Jack Dorsey"

The problem isn't fitting the 120 bit did PLCs into the 160 bit Kademlia key space. The problem is the DHT is a best effort eventually consistent data structure.
We want an identity service that can give an authoritative latest version of the DID document.

As for the contents of the repo's someone has to store the objects. You could publish to a DHT but the nodes come, go, and clear cache out side of your control. What is the insensitive to store data for others on your DHT node.

We end up better off with an authoritative identity service and PDSs that are accountable to their customers and only relying on the DHT to be a cache to improve latency and robustness

It is funny the way
Hedge fund Elliott Management Corp is responsible for Jack's motive for Bluesky back in December 2019

https://www.cnn.com/2020/02/29/tech/elliott-twitter-jack-dorsey-replace/index.html

How do you protect Twitter from an activist investor who might buy Twitter and shut down the API?

Like this:
https://twitter.com/jack/status/1204766078468911106?t=nddAB0WEUCkqwMgXlN4juA&s=19