right, that’s actually how SPECIFIC KEYS are referenced in DID documents! Dmitri and i are both very familiar with that notation, and silverpill’s FEP about using the Data Integrity signing mechanisms assumes it AFAIK.
Dmitri’s idea about how to make a static “passthrough” Actor would probably be unrealistic for practical reasons if it had to, say, be one gigantic JSON-LD file that contained every post dereferenced by fragment identifier, but perhaps the next best thing (if the goal is turning making every URL “still just work” despite migrations) is a combination of independent actor and… dynamic SolidPod? It’s a fun idea to kick around but since the “static independent actor” thought experiment is currently on hold it’s not exactly urgent to my weekly to-do list 
1 Like
we think it might be worth raising an issue somewhere (where?) about ActivityStreams 2.0 fragment identifiers, to bring them in alignment with json-ld.
tbh im not sure whats out of alignment but my guess is that unless there’s something explicitly contradictory in either spec itself, an issue on AS or AP wouldnt be justified , and even if it were im not sure it would get prioritized at the moment. If, however, you are building an implementation and you use matrix parameters in a way allowed by those specs that you think others would benefit from maybe doing as well (an opt-in extension, for example, ideally one that is backwards compatible for other implementations who dont implement it), write a FEP!
As a response, I’m trying this out: PieFed accounts now have two profiles within them - one used for posting content and another (with no name, profile photo or bio, etc) for voting. PieFed federates content using the main profile most of the time but when sending votes to Mbin and Lemmy it uses the anonymous profile. The anonymous profile cannot be associated with its controlling account by anyone other than your PieFed instance admin(s). There is one and only one anonymous profile per account so it will still be possible to analyze voting patterns for abuse or manipulation.
ActivityPub geeks: the anonymous profile is a separate Actor with a different url. The Activity for the vote has its “actor” field set to the anonymous Actor url instead of the main Actor. PieFed provides all the usual url endpoints, WebFinger, etc for both actors but only provides user-provided PII for the main one.
Is that 
doing something similar/compatible with this FEP?
Wow this is a fascinating read, thanks for sharing.
I think (hope?) it’s completely orthogonal, because the linkage between the public actor and revocably-server-pseudonymized actor is secret (at least until it isn’t), while a public-actor just makes the public actor longer-lived than the service-provider relationship with that actor’s current services (which are all bundled up as one monolithic service in most cases today). The tricky bit about composing that extension and separate-actor guarantees is that the trust model gets a little dicier. To wit:
- Alice hosts an actor independently, but uses server X (piefed) to read and vote on threads.
- Bob posts a thread on server Y (lemmy)
- Alice downvotes Bob’s dadjoke anoymously.
- For server Y to register Alice’s anon downvote, it needs to trust server X to enforce one vetted/hopefully-deone anon-voter.
The independent-actor doesn’t really make that trust decision any more or less enforceable, if all the implementations that do anon-voting in a way that enforces one-human/one-anonvote uniformly. but I do wonder about knock-on effects, like preventing an independent actor from unbundling some services (needed for that deduping/trust-establishment step)… have to see where they land with all this.
2 Likes
er, one vetted and hopefully-de-duplicated anon-voter