Introduction

This is my idea for how a distributed, federated, end-to-end encrypted dating app could work taking into account the guaranteed probability of violence against minority groups. The app aims to balance human rights (privacy) with usability; however, privacy is more important than usability, and privacy must not be sacrificed in order to increase user adoption. This app doesn't aim to solve societal problems, only to reduce tech harms. Inspiration for this app includes: Ricochet, Cwtch, Ricochet Refresh, and Tinder.

This blog post is licesned as Attribution-ShareAlike 4.0 International.

If you like this idea, i'd appreciate it if you would Signal me, provide a clear introduction of yourself if I don't already know you, so I can add you to a Signal group for any future discussions around this idea's development.

Principles

PR1. The use of Tor onion services is paramount to protect physical location data and must be used.

PR2. Users must be in full control of their data.

PR3. Application controls must use privacy-first defaults.

PR4. Nodes (client or relay) must maximize decentralization and federation principles.

PR5. Disabled people are a huge part of society and accessibliity must be designed with care.

PR6. The client and relay applications must be cop resistant, both in terms of data and metadata. See PR1.

High level data flows

HL1. There must be a client app and a server app (a relay).

HL2. A user opens the app. Creating a profile is local, and the app generates a Tor onion service address, automatically connecting the user to the Tor network. At this point, there is no connection to any other users since no other user identities are known.

HL3. Since Tor onion services cannot discover each other, an intermediary application server (herein called a relay, not to be confused with a normal Tor relay) is necessary to kickstart federation.

HL4. A different (or the same) user can create a relay. See the relay section below.

HL5. All connectivity, be it client-to-client, client-to-relay, or relay-to-relay is only performed over Tor onion services except in the scenario where a client or relay is provided a clearnet identity. Once a first connection is made from a client-to-relay, or a relay-to-relay via a clearnet connection, the associated Tor onion domain is shared with the client or relay, and all future connectivity is only ever made via Tor onion services. Client-to-client and relay-to-client connectivity is only possible via Tor onion services.

HL6. This specification is platform agnostic; however, due to the design of clients, relays, and offline private messaging, phone apps must not be designed to be always online. When online, consider bell-shaped-curve network-metadata surveillance resistance (see Pond.)

The relay application

RE1. Hosting a relay always requires hosting a Tor onion service, which can happen from anywhere and does not require a static IP or publicly-accessible server.

RE2. Optionally, a relay operator may use an owned clearnet domain name if the relay operator and/or community wishes to use a clearnet domain.

RE3. A user, knowing a relay domain, either its Tor onion domain or its clearnet domain, adds a domain to their client application. Doing this joins a user to relay for application discoverability.

RE3a. If a relay has authenticated itself via DNS in order to establish a clearnet identity, the relay must be directly available on the internet like a normal DNS- or dynamic-DNS-based HTTP server. TLS certificate automation should be used.

RE3b. If a relay has authenticated itself via DNS (something.net) in order to establish a clearnet identity, the user (user 1) of the relay will be prompted to adopt the relay's clearnet identity (someone@something.net). However, the clearnet identity is only superficial, and only ever used for other users (user 2) to become aware of the relay's associated Tor onion domain, whereas all future communications will only ever take place over Tor onion servies. Clients are never accessible over clearnet. If a user (user 2) enters a clearnet domain into their app to discover its user (user 1), user 2's client first obtains the relay's Tor onion domain, then communicates over Tor onion services to the relay, and the relay provides the Tor onion identity of the user 1 to user 2. Going forward, federation is direct, user to user, if and when user 1 permits any data or metadata sharing (see CL0 below).

RE4. Attaching a client to a relay allows a user to establish themself with a memorable identity beyond an onion service domain. A user can detach themselves from a relay at any time. For example, if disobey.net is an application relay, users can establish themselves as someone@disobey.net for easier identification.

RE5. The relay will temporarily cache client Tor onion service domains, for up to one week, of clients in an end to end encrypted way so that the relay cannot know anything about any clients.

RE6. Clients connecting to this relay directly will be provided only a current listing of other known Tor onion service domains. These onion domains are client addresses. A client, with a list of other client addresses, will store the list of addresses for up to one month.

RE7. The relay, similair to how clients work, can manually add other known public relays. Doing so allows relays to share and load-balance other relay identities and other client identities.

RE8. Relay operators can either explicitly set a list of known, trusted relays for federation, or, relay operators can set a maxmimum limit of relay hop trust. In the case of setting a relay hop trust number, relay operators, who trust one relay, who set a trust hop number of 1, will in effect automatically trust any relays trusted by the relay that they explicitly trust. This aims to reduce complete trust of all relays and minimize the use of malicious relays. Relay operators can also enable automatic trusting of all relays.

RE9. The function of a public relay can also act as closed community. By default, relays do not know of other relays, and so they cannot talk to other relays. A group of people can host their own private relay, and in doing so, allow communities to mingle among themselves in an isolated way. See C0a - C0c below.

RE10. Relays must support block lists. They can defederate from either a clearnet domain or from a Tor onion domain, or both. Defederating then applies automatically to any client using the identity of the relay. This is an attempt to slow down and avoid serial stalkers.

RE11. Relays are responsible for keeping track of, in an end-to-end encrypted way, clearnet identities to onion identities. This way, even relay operators cannot connect identities to real people, and users have absolute control over how and when they share their identities with people (see C0 below).

Private messages and private caches

PM1. The relay, in an end-to-end encrypted way, acts as a private message (PM) cache.

PM2. The relay will automatically purge private cache (PC) data after 30 days if no client downloads the PM.

PM3. If clients come online and download their PMs, the client initiates a relay wipe of any of their cached PMs.

PM4. PMs can be text, media, or any file type.

PM4a. Any uploaded media, client-side, must wipe all media or file metadata, before being end-to-end encrypted.

PM5. Relays can set a max message size quota and will default to 1 MiB.

PM6. Relays can opt-into temporarily matching a quota size of a federated relay when one relay is acting on behalf of an offline client in consenting PM relationships.

PM7. Outbound PMs are first directed toward the consenting client. If said client is not online, the user's client will store the PM in their relay's PC. If the outbound PM is for a user with a different relay identity, the outbound PM is also stored in the other relay's PC. Therefore, outbound PMs can be stored in two different PCs. When the receiving client automatically downloads one or both identical PMs, their client will discard duplicate PMs. Therefore, if one of the two relays goes offline, one copy of a PM will remain avaible online.

PM8. When clients come online, they will periodically check their relay's PC for PMs. Also, for any consented connections from any time in the history of their profile, a client will periodically check the other relay's PC for PMs, based on the identity of consenting matches or established PMs. However, if any relay goes offline, including the user's identity-relay, after 30 days of being offline, clients will cease attempting to query the associated relay's PC.

PM9. If and when relays opt-into being globally federated (not just a community relay), in an end-to-end encrypted manner, PCs will federate with each other to help inform connecting clients of any PMs and automatically share end-to-end encrypted PMs belonging to the associated client of a consenting conversation. This way, if a client was able to store an outbound PM with one server but not the other, based on consenting client relationships, PMs will federate to the associated relay. Therefore, PMs should always be redundantly available while clients are offline.

The client application

CL0. By default, the user can opt-into:

CL0a. No profile sharing, and only limited profile sharing with manual approval. Before selecting a CL0 option, the client will default to this option. In this scenario, other users have no access to data or metadata, which includes seeing if and when the user is online.

CL0b. Limited profile sharing (automatic) to clients using the linked/community relay only.

CL0c. Full profile sharing (automatic) to clients using the linked/community relay only.

CL0d. Limited profile sharing (automatic) to any client.

CL0e. Full profile sharing (automatic) to any client.

CL1. Once the client has discoverability via a relay, and the relay provides a list of other clients to the connecting client, the client will connect directly to other clients for client-to-client discoverability. At this stage, it is not necessary for the the other clients to be online. Also at this stage, relay connectivity is not necessary, but still maintained for periodic checking of new clients. The user's client will periodically check to see if the other clients are online. However, depending on the other client's settings defined in C0 of this section, the user's client may or may not receive profile data from other users.

CL2. Once the client has discoverability, either via relay or direct clients, depending on their CL0 setting:

CL2a. (in the case of CL0a) The user is always in full control of their data. The user will see other client profiles who have opted into CL0b - CL0e. The user will not be sharing any of their user data with anyone by default. All other clients can know about the user is that there is an unknown client and there will be no way for another user to be aware of the user's data or online presence. At this stage, the user is able to "swipe left" or "swipe right". If the user swipes right, the user will be prompted to share data (CL0b, or CL0c) with only this user.

CL2b. (in the case of CL0b) The user will automatically share limited profile data with any other discovered and online clients provided by the community relay. Any other clients that the user's client may have discovered, if they were not dicovered via the community relay, will never establish connection to said client. The user will see other client profiles who have opted into CL0b or CL0c. At this stage, the user is able to "swipe left" or "swipe right" on profiles. Also at this stage, even if a user has not swiped right on a profile, other discovered clients will be able to "swipe left" or "swipe right" on the user's limited profile. If there's a mutually consenting match (when both users have "swiped right" on the other), the user is prompted to opt-into sharing their full profile with this user, or not. At this stage, the two consenting users are able to private message each other (see P7 above). In no other situation are PMs possible.

CL2c. (in the case of CL0c) see CL2b, but instead a client will share full profile data instead of limited profile data.

CL2d. (in the case of CL0d) The user will automatically share full profile data with any other discovered and online clients. The user will see other client profiles who have opted into CL0d or CL0e. At this stage, the user is able to "swipe left" or "swipe right". Also at this stage, even if a user has not swiped right on a profile, other discovered clients will be able to "swipe left" or "swipe right" on the user's full profile. If there's a mutually consenting match (when both users have "swiped right" on the other), the user is prompted to opt-into sharing their full profile with a user, or not. At this stage, the two consenting users are able to direct message each other.

CL2e. (in the case of CL0e) see CL2d, but instead a client will share full profile data instead of full profile data.

CL3. Users can create any number of Tor onion domains for their client, effectively giving them unlimited identities. Once a user deletes an identity, the user cannot be contacted via that identity. This is to enable users to hand out identities to different people or groups. See RE11.

User risks

UR1. Using privacy apps requires careful understanding by its user. Education is paramount and good UI/UX is paramount. Users may accidently overshare not fully understanding the consequences.

UR2. Anyone in the world can sign up and use this network. Liars. Cheaters. Government agents. Stalkers. Rapists. Murderers. A huge amount of insecure and insecurely-attached people. It's dangerous. See UR1. There is no central organization to complain to, no central organization to ban people, to central organization to demand fundamental rights from. It's all on you and your communities to stay safe.

Relay risks

RR1. Typical government user data demands or server seizure, even though there's literally no user data and no metadata that can be obtained, stored, shared, or seized. This is only ever an issue if and when a relay has an associted clearnet domain.