Which is why we have keys as well as usernames. If a friend looking for you at

nick@example.com

gets a 404 tomorrow, they go find what update your key has signed to discover your new host/username.

Sorry I'm jumping back a little. I just ran into this federated ID issue too.

A difficult thing about universal IDs is that the browser generally only gives you storage per domain. That plus the webcrypto API means that you cannot re-use a private key across multiple domains. This is a place where a UCAN-like document can be useful, so you can say "DID2 is the same as DID1" and sign that message.

Here a server could only have record of docs that link directly to itself, so here, server a only has record of a link to serverb — a -> b -> c

But a client I suppose could recursively resolve all of the identity mapping

Profile info is the most immediately relevant thing here. A single object of data that could be relevant to many DIDs. So for example DID A changes their avatar. Does DID C know about that?

This is where having a server of identities becomes useful. So that there is a 'source of truth'. You would need to create a DAG map of identities in the distributed version, not, say, a graph without direction, so that way there is always a flow of authority in updates.

The only arbiter of truth should be your PrivateKey. Shouldn't matter WHERE the signed data is found. A single source of truth governing usernames would be controlled by that central authority, and they would immediately begin censoring people based on their political viewpoint.

We can't let a single centralized service have any power whatsoever over the network, or it can be used to cancel people. Hopefully that's not what you meant.

Right, I would consider the least-common-denominator type of capability would be that if I want a permanent PublicKey that neither I nor anyone else can ever change, validate, or even "sign off on", then that should be the simplest use case and just work, without me doing anything special, like running my own Consensus Group Server, or anything else like that.

All that advanced stuff will be cool, but should be "opt-in", rather than required, and able to be simply ignored by developers trying to participate in the network with minimal amount of coding. Perhaps even coding in Java or creating CAR files directly, and not even using the BlueSky TypeScript library.

hard to tell exactly without seeing the code/package.json

• make sure that the package is built (run yarn build from directory root)
• install the package in your workspace with the relative path (yarn add ../adx/common or whatever the path is)

lmk if that works 🙂

There are places you might expect semi-public data to integrate.

You want the ability to pull data from multiple sources. For example you may have a large index like a Twitter or Facebook but also pull from a tiny index like your local bowling league. The home server should be able to combine posts from different indexes into a unified timeline.

While we haven't really thought it through you could imagine an index that required authentication to access e.g. your kids school we're only people affiliated with the school could access the index and it only indexed people affiliated with the school.

It's a natural starting point for communities of different levels of openness but requires really thinking through the ways in which data might leak from one community to the other.

I do some times wander how far we can get with machine checked etiquette.

"
Did you notice: You're about to share a message from a private server to a public one.

Are you sure?
"

May be worth distinguishing groups into some different use cases.
Channels, Communities, and Circles

Channels: limited publishers, self selected consumers
Communities: limited publishers, limited consumers
Circles: limited publishers, publisher selected consumers
Hashtag: self selected publishers, self selected consumers

hey Daniel Holmgren finally looping back on this! we (that is Nishant Sharma ) figured it out, put up https://github.com/blueskyCommunity/use-adx-demo

Looking forward to playing with it more as the new stuff comes out!

However the current models suffer from a great deal of runtime overhead, the gas-fee incentive to pre-optimize, and the existence of subtle complexities which lead to bugs.

Yes this is true and smart contracts suck for this reason, your mistakes when optimizing are also eternal and can't be changed. You don't need to run programs in a distributed context with a requirement for consensus about what they do ie blockchain for them to be useful though. The biggest use case would be rendering & interaction. You would need consensus or reproducible/verifiable computation to be able to restructure the fundamentals (e.g. the very nature of the event log) but that doesn't seem to be something that is needed.

I will look at objecthash but for how I think about this generally:
This tends to be a speed vs flexibility tradeoff. I could have a system where all Dicts, Lists, and Strings are treated as trees. Then when I need to hash build a merkle tree with the values. If I ever need to redact a value then I replace that value with a tombstone that indicates that the value is unavailable and to use this hash in place of that sub-tree. This means running the cryptographic hash function more times. If not carefully implemented this frequent restarting of the cryptographic hash function can lead to an explosion of allocations as you scan over the dataset consuming memory bandwidth and leading to a significant slowdown.

If we don't want this we can set a minimum size for the redactable chunks. E.G. we could make a distinction between a large Dict, List, String, Bytes and small ones. We can build a CBOR object until we reach some threshold size say 1452 Bytes or 128 KiB and then if it is to large replace the Dicts and Lists with

pfrazee: Golda Velez Aaron Goldman

I’m interested in joining this call as well.

Hello dear Bluesky team. Anton from Anytype team here.

I have a question about The DID Consortium:

The (currently-unnamed) DID Consortium will securely host user IDs. It will be operated by multiple different organizations who share ownership of the service.
Consortium members will operate nodes which coordinate under a control plane run by the consortium governance. They will coordinate reads and writes to a secure append-only log which can be monitored externally, through a technique similar to Certificate Transparency.

Does that mean that Consortium acts like a "public permissioned" service and no end-user will be able to run a node to store DID Documents?

Could you please explain what is the idea behind that design choice?

The Consortium will be a permissioned ledger. It will be one of the way to store and version DID Documents. The user will need a DID to publish a repo. This could be an immutable DID like DID key. If the DID Document is to be updatable there must be a consensus group to determine the latest version of the document as of some time.

For example if you control a domain name you could use a did:web: if you want to use a public blockchain you could use something like did:ion:

The goal with the DID Consortium is to provide users a cheap consensus group they can use to advertise the latest versions of there did documents without needing to run that infrastructure themselves and have reasonably good availability and latency for resolving did documents.

This consortium should be optional for any user but they will need some form of did that can be resolved to a did document.

Depends on what you mean by block chain. We do use hashs as content IDs (cid) but there is not a singular public ledger to totally order events.

If you have more questions you came to the right place 😁

Here’s the JSON-LD W3C draft

https://w3c.github.io/json-ld-cbor/

pfrazee: there's been some thought from protocol labs about private access to graphs of data. there's a funding call out for research at https://research.protocol.ai/blog/2022/announcing-rfp-014-the-one-with-private-retrieval/, and a set of recent talks https://www.youtube.com/playlist?list=PLuhRWgmPaHtTegfLTVFYtTtqTKQEtDvxW that might be interesting.

There's some hope that homomorphic encryption and/or private set intersection may be able to help with some of this privacy issue in not too many years

Yup, background checks are about adding reputation to someone who is at zero.

Then you can treat zero as default deny.

You solve the negative reputation problem by not needing 'negative reputation' because you don't trust zero.

Bluesky was always meant to be independent. The goal was a small group of protocol engineers to build a protocol for public broadcast content to move between Twitter and other networks.

That's why it's structure is a research grant not a subsidiarity. Twitter is not even a share holder.

The protocol needs to be neutral territory or it won't be trusted or adopted by anyone outside Twitter.

https://twitter.com/jack/status/1562861302242226178