gits-r-us

instances use https to establish identity of the other server but don't reuse RSA certs for the secret transmitting a separate public/private keypair is generated using curve25519 which is then put in a sodium 'crypto_box' - this is what gets transmited to the remote site - the details are here --> https://notabug.org/hp/gits-r-us/src/master/lib/macaroon/macaroon.cpp#L181

the receiving instance will then unpack the (now shared) secret from the crypto box, verify the original identity from the requester and if successful create a so called 'discharge macaroon' which can be presented to the Q1[third party] as proof - the details on this part are here --> https://notabug.org/hp/gits-r-us/src/master/lib/macaroon/macaroon.cpp#L298

a user-client starts off logging into it's home server which will Q2[generate a macaroon] that is only good for your username at your home server (we will call this the 'session macaroon') - you can see what a client would do starting here --> https://notabug.org/hp/gits-r-us/src/master/src/gits-r-us.cpp#L129

a client "logging-in" to a third party site must present a Q3[username], the remote site will then create a macaroon with a "third party caveat" (we will call this the 'foreign macaroon') meaning that that macaroon is useless unless you pair it with another macaroon (namely, the one generated by you home server as previously described) - the client is then redirected back to their home site and presents this third-party secret together with the home server session macaroon Q4[both stored in LocalStorage] to prove authenticity - if the authentication succeeds, then the home server uses it's private key to decrypt the shared secret and create a NEW temporary macaroon for the client's identity that uses this shared secret (we will call this the 'discharge macaroon') - the client then sends back this 'discharge macaroon' together with the 'foreign macaroon' macaroon from the third party. The discharge macaroon should satisfy the "third party caveat" then the third party site Q2[generates a normal 'session macaroon'], much like the one the home server generated, that client is then essentially "logged-in" to the third-party site as if it were a local account - to be clear the user does NOT have an account on the foreign server - users have accounts ONLY on their home server

Q1: there is confusiong here about who is "requester", who is "receiver", and who is "third-party"? - this begins by talking about two servers exchanging certs - no clines have yet been mentioned - is "third-party" the user-client and/or web interface? or is this yet another third-party server

Q2: which is the case?: the server generates a macaroon and holds it in "session" the server generates a macaroon and holds it in "session" and delivers it (a reference to it) back to the requesting client the server generates a macaroon and and delivers it (or a reference to it) back to the requesting client without storing it (or anything stateful)

Q3: username or simply home server redirect URL - see RFC #5

the language of "logging into the foreign site using your home credentials" that is particularly confusing - i dont see why the user should ever feel as if they are "logged into a foreign site" - i think many will have a bad vibe about that - otherwise this raisees the issue that it will appear to users that ALL such participating servers are endorsed, vetted member sites of the by THE official notabug federation - i would try to make it extremely clear from the user perspective that their home server handles all of their interactions - except for that one time you tell the foreign server your home URL (although it has been said the home server does NOT handle all of their user's interactions)

Q4: where does the client store the home server session macaroon and third-party per-request macaroons? javascript LocalStorage? what about CLI and email clients?