Interesting :)
A few quick questions & comments:
-
I don't quite understand "If all users accept the introduction, a list of contacts is sent for each contact pair. These contacts are not used for messaging to prevent more than two parties from having encryption keys." (line 66) What exactly are the "contacts"? Is it the same data as defined on line 8? Where do the encryption keys come from? Do initiators of introduction reveal encryption keys of their existing contacts?
-
After an introduction there's the problem that newly introduced people cannot setup secret keys in a very clean way. Because this secret keys can be computed if an attacker gets hold of the introducer, has recorded traffic and is in possession of a large enough quantum computer (which you assume in your threat model). You therefore would need some sort of 'upgrade' mechanism which would allow either two people to meet in person to 'upgrade' their secure channel. Or you could add a asymmetric key-agreement or key-exchange on top (probably post-quantum algorithm).
-
I don't quite get the combination of "HTTPS", "Tor", "symmetric crypto because of quantum computers". Why HTTPS if Tor already provides confidentiality? HTTPS implies certificates, no? What about them?
-
What about nonces for GCM? How do you prevent replay attacks?
-
If you want to truly understand your protocol and get confident about it, I recommend studying something like this: https://tamarin-prover.com/ This allows you to model your protocol more formally, state your security claims and check if the protocol satisfies this claims :)