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
Yes, exactly.
I don’t think things need to be SDS aware at all.
Apologies for losing focus, if no one tags me i forget to bloviate publicly with my baroque opinions.
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…