Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

consider domain-agnostic terminology for protocol participants #21

Open
cfm opened this issue Oct 27, 2023 · 7 comments
Open

consider domain-agnostic terminology for protocol participants #21

cfm opened this issue Oct 27, 2023 · 7 comments
Labels
documentation Improvements or additions to documentation

Comments

@cfm
Copy link
Member

cfm commented Oct 27, 2023

The asymmetry made explicit in #18 is one of the fundamental properties of this protocol—indeed, one of the symptoms that motivates having a custom protocol at all, versus Signal or MLS.

Within that asymmetry, however, the "journalist" and "source" roles are features of our domain, not of the essential protocol. Whatever names we expose in APIs, we may be able to come up with domain-agnostic terminology for these roles based on how they participate in this protocol.

@cfm
Copy link
Member Author

cfm commented Oct 27, 2023

For example, if we consider the first volley to be an instance of the first-contact problem:

  • Source → initiator
  • Journalist → responder, respondent, etc.

Subsequently, if we consider the statefulness of the participants:

  • Source → stateless party
  • Journalist → stateful party

Or their PKI status:

  • Source → anonymous party
  • Journalist → authenticated party

Or their one-to-potentially-many relationship:

  • Source → outside party
  • Journalist → inside party or inside set

To be continued....

@cfm
Copy link
Member Author

cfm commented Dec 19, 2023

Two analogies to chew on:

  1. In an online community, an original poster (OP) is immutable once they've started a thread, no matter what conversation follows and no matter what role (if any) they play in it. SecureDrop sources are always original posters: they start the "thread" (in a one-to-one relation), no matter how much back-and-forth follows with any number of journalists.

  2. In the law, a petitioner is similarly immutable once they've filed a suit. This echoes initiator/respondent above, but in this case there is a third party: a government, specifically a court, which is hardly analogous to a SecureDrop server.

The challenge here is to describe the enduring asymmetry of the participants' original conversation- or protocol-level roles, which have implications for, but are not identical to, their roles at the level of any given message, exchange of messages, or window of time.

@lsd-cat lsd-cat added the documentation Improvements or additions to documentation label Dec 22, 2023
@lsd-cat
Copy link
Member

lsd-cat commented Mar 27, 2024

I think given that now we have plenty of documentation, the audit, multiple diagrams and we are preparing for public disclosure, this is a good time to start finalizing the terminology and make things as consistent as we can.

@rocodes
Copy link
Contributor

rocodes commented Dec 20, 2024

Coming back to the idea of more generalized terminology, which I think is a great idea especially at this point.

Of @cfm 's suggestions I prefer the ones that are non-metaphorical and are about roles and not the internal protocol features, such as

Source → initiator
Journalist → responder

(or some similar variant, I wish there was a more common word for "initiator" that was more like "OP").

I also wonder about relying on existing familiar paradigms like "Sender/Recipient" ; although it's tricky because those roles obviously can switch, AnonSender and KnownRecipient/KnownResponder is another option.

@zenmonkeykstop
Copy link

Statefulness distinction seems to make the most sense IMO. 👍 for that option.

@rocodes
Copy link
Contributor

rocodes commented Dec 20, 2024

Would you mind saying a bit more about why you like the statefulness/statelessness one? I'm not trying to quibble, but I'm thinking about documentation that will eventually be out in the world (trying to document an eventual protocol library), and already "Stateful Party" / "Stateless Party" feels kind of abstract and confusing. I don't read those words and automatically think of two human parties/user groups communicating, I'm working to parse what it means. Or if I'm a tool-builder, I don't read those terms and have a clearer idea of whether this protocol library will/won't work for me than if I were to read "source" and "journalist".

@cfm
Copy link
Member Author

cfm commented Dec 21, 2024

@rocodes in #21 (comment):

I also wonder about relying on existing familiar paradigms like "Sender/Recipient" ; although it's tricky because those roles obviously can switch, AnonSender and KnownRecipient/KnownResponder is another option.

I think this is what I was getting at in #21 (comment):

The challenge here is to describe the enduring asymmetry of the participants' original conversation- or protocol-level roles, which have implications for, but are not identical to, their roles at the level of any given message, exchange of messages, or window of time.

Like you, I think I still favor initiator/respondent. For Friday-afternoon fun I've dug out Roget's Thesaurus and am surprised to find it doesn't have a lot more to offer us (emphasis original):

886 cause

4 author, agent, originator, generator, begetter, engenderer, producer, maker, beginner, creator, mover, inventor; parent, mother, father, sire; prime mover, primum mobile <L>; causer, effector; inspirer, instigator, catalyst, mobilizer; motivator, inspiration

5 source, origin, genesis, original, origination, derivation, rise, beginning, conception, inception, commencement, head; provenance, provenience, background; root, radix, radical, raproot, grass roots; stem, stock; etymology

939 answer

3 answerer, replier, responder, respondent, responser; defendant

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

4 participants