Part of the problem is that there's no shared definition for "verified"; the corollary is this question of how verification badge(s) should be shown.

I'll be a broken record and argue that re: the first question, we shouldn't have a shared definition and re: the second, panproto could help.

More concretely: what does it mean to be "verified" by 2048.blue, which has actual verification/stats records.

Oops, I didn't mean to reply to this specifically. 😅

I was going to say that panproto could be useful for handling "all the lexicons" but that was before I'd read the full post. It would still be useful for handling mentioned lexicons without having to actually understand what they're up to at the leaflet level, though!

This is extremely cool.

Thanks for doing all this work and thinking-in-public, Daniel!

As you know, I'm not one to dwell on details, and I've largely nodded along in agreement with the previous posts. I'm still not going to dwell on details, but this post raises a couple of thoughts:

- first, a facetious one: My prophecy of the atproto-activitypub topological equivalency has been fulfilled! Huzzah!
- more seriously, I'm actually really into how you're thinking about access control here, and I think it's meaningfully different from previous push models.
- that said, I worry about the dual protocol thing. For all its ills, the Authorization header in http proved to be a sufficiently expressive primitive; even more than was initially envisioned, I think. If we had two separate HTTP verb sets, the complexity would be really problematic. There's probably case-law in SOAP and others.
- my main (not rhetorical!) question here is "what do you lose by taking this new approach, assuming 'public stuff' is in a 'public group' and dropping the `at://` protocol entirely in favor of this one?"
- my vaguely-informed hunch is that you can compose or slightly tweak things like sync and subscribeRepos with ats, but perhaps the inverse isn't true? If that's the case, my "we didn't do oidc from day one only because we didn't want to undermine the hard work that the OpenID2 folks had done" experience suggests that it's worth doing the unifying work up-front.

Anyhow, thanks again for sharing, great to see this progress, and I'll be looking (in my copious spare time, lol) to figure out what this would change/apply to the model we've used for roundabout in particular (as we've discussed, I don't think it'll be a huge lift for us to implement - but the multiprotocol thing is a concern).

Great question!

I think this PDS Proxy approach could work for any "pre-commit" workflow: approvals, conditional embargoes, etc (I'm currently working on adding support for webhook-triggered delivery and scheduled delivery with dynamic content!). We use a similar system for Roundabout's pre-moderation system.

I haven't dug into how "choosing your write PDS" could work at an account level (think: swap out your PDS like you swap feeds or labelers), but this could allow writing to multiple PDSes, or keeping a backup separate from your primary PDS, on every post.

More generally, though, I think atproto just lends itself really nicely to "protocol thinking"; it really is like HTTP that way. As a bit of an annoying koan: "Not all lexicons are programmable, but all lexicons could be programmable." 🧘‍♂️

I think it'll take some time for us to suss out the patterns, but I'm certainly excited for that future!

This is something we've been thinking about in the context of Roundabout, too! We're not currently/actively working on it, but have some designs from last summer that point in this direction (there's only so much time! 😭)

Slightly on the side of Roundabout stuff, I'm playing with a tool that might make some of interop pieces you're pointing at easier. More on that soon!

Nice writeup!

For what it's worth, the way I'm approaching this is the community DID. Great confirmation of the approach that you're thinking along similar lines!

It's very experimental and early (and, sadly, not open source yet) but the way it works is to just have the community DID as a very lightweight identity handle to start.

When someone wants to join the community, they write a "join community" record into their PDS. I have a bot that watches the firehose, and when one of the "test.xoxo.group.membership" posts comes through (assuming some conditions are met), the bot follows the associated DID.

Posts intended for a group will have "to" attributes that address the group (I haven't figured this part out in detail yet!).

Currently, the way I've implemented the "community feed" is that it's just ... the community feed!

One of the nice things from a control perspective about this approach is that the community can be forked, retaining history. Retaining membership is harder (since it should depend on the group membership record in the member's PDS), but that's a social problem, and the technical fix is trivial.

It's also nice that groups can "collect" posts of any type without any extra work beyond the "to" attribute (comparable to the reply attribute on posts).

As an aside, in practice I'm *also* using the NSID approach, in a manner of speaking, since I've added a did:web discovery attribute for the group.

This broadly maps to my read of the situation, thanks for writing it up. I've stressed in other contexts that I feel pretty strongly that it would be a mistake to iterate on potential protocol-level approaches before really understanding the use-cases, so I really appreciate your approach here.

A few high-level thoughts:

- Trust in these contexts comes from the users not the software or the protocol. If someone I want to share private data with uses software that they don't trust to respect that privacy, well ... no amount of protocol-level work is going to solve that (even for e2ee and local-first approaches, even if those approaches can help reduce the number of bits of software that we need to trust!)

- From a protocol user's perspective, I feel reasonably strongly that private data should be accessible through the same API surface as public data (i.e., public data should be private data that is accessible without permission, via the same mechanism). Having to write essentially a parallel set of code to handle private data would be a mess.

- My intuition is that making permissions simple at the PDS is critical, and that Relays and AppViews will also need to be able to reason about permissions (i.e., having an authenticated request that the PDS transparently responds to with variable data isn't going to be a good solution).

FWIW / as an example of the latter point, Twitter had private accounts from the start, AND (and this is wild in retrospect) any user could see any other user's timeline. Except we obviously needed to ensure that if public User A followed private User X, public User B fetching User A's timeline shouldn't have been allowed to see User B's post, even though they were in User A's cached timeline. This is 100% an AppView concern. And was expensive and complicated as hell to implement at scale (i.e., there are good reasons that feature got removed).

As I've been thinking about private data in the private-first atproto project I've been working on, I think that those requirements and assumptions present both challenges and opportunities – both for enabling interesting user focused use-cases, but also in terms of protocol and application design.

One thing I'd love to do is find a way to have a forum for our product folks to get involved in this discussion. Challenging, given the inherent technical nature of the problem, but probably worth pursuing (we're probably two months out before our folks could engage, fwiw).