Hypercerts: Recognizing and Rewarding Impact – ATProto Implementation

[thisismissem.social]

For SDS you wouldn’t actually need to modify the PDS, just create a wrapping service that has XRPC calls to interact, whilst proxying the write endpoints (assuming public but shared writer storage).

You can quite easily have methods for interacting with an underlying repo in a shared manner as a separate service that creates the account & stores its password/app password. That then just mediates writes to that PDS. You could still do first party writes that way too

[bmann.ca]

Yes, exactly.

I don’t think things need to be SDS aware at all.

[bumblefudge.com]

Apologies for losing focus, if no one tags me i forget to bloviate publicly with my baroque opinions.

@adamspiers.org

The full audit trail would only be available by combining app logs with SDS logs:

1. The app would know which organization DID performed an operation.
2. The SDS would know which user was issued which auth token to act as the org.

I think these are separate questions. As long as the SDS knows which member did what (and can handle the corner-case of that member later being removed from the group), the app that cares (and no other apps) need to know what an SDS is and how to get audit trails from it. I agree that ideally (in the unlimited-resources-and-time parallel universe) this should be configurable and some apps would want to re-publish these audit records as public records, via firehose or chainstate or public-IPFS or otherwise. but it’s fine for the SDS and the App-that-cares to communicate off-protocol, via smart-contract, via API key, etc.

And to Emelia’s point, this complexity doesn’t have to be at the SDS/PDS level or that of any other ATPism– it could be at the OAuth scopes level (is that stable yet?), or work via fancy custom OIDC à la Nick’s GitHub - graze-social/aip: ATmosphere Authentication, Identity, and Permission Proxy . One of these latter two approaches is probably the one of most interest to gigantic conventional/web2 systems, because it lets them keep all their current SLAs and middleware contracts and cybersecurity guarantees, yadda yadda, so that is probably the route that someone (smart and well-funded) will follow if a stable groups-abstraction gets defined for the protocol, which would open the door to lots of existing groupware to bring entire userbases onto the protocol…

[adamspiers.org]

I do agree that the conceptual simplicity, architectural cleanliness, and backwards compatibility of this wrapper approach is very compelling indeed.

However, it does require trade offs in functionality, e.g.

• The app will show that the user is logged in as the organization, which is inconsistent with the fact that they used their personal credentials to log in.
• Apps working this way cannot support a user being connected to multiple organizations within one login session, like you can on many websites (Facebook and GitHub being the first examples which come to mind)

and in security, e.g.

• The organization username and password have to be custodied in the clear by the proxy, which creates a potential honeypot. Encryption at rest would only partly mitigate this.
• Unless the code which generates and consumes those org credentials is all run in a TEE, it means that someone is able to act as the organisation without any accountability / auditability as an individual.
• It could get complicated if the underlying PDS hosting the org repo required 2FA rather than just username + password.

The question is whether the benefits outweigh the trade-offs, and also whether this kind of proxy really is simple when it comes down to the implementation. Given the similarity to entryways, @thisismissem.social seems ideally placed to comment on that.

In a world of unlimited resources (which we are arguably getting closer to with AI), probably both approaches are well worth trying, and I’m certainly very interested in both.