Introduction

This is my idea for how a decentralized, federated, end-to-end encrypted dating app could work taking into account the probabilities of violence against minority groups. This high level design document of a theoretical 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. I am not a developer -- so I will not be building this app. However, I can help facilitate, educate, and help fundraise.

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 a clearnet domain name (for example, disobey.net) if the relay operator and/or community wishes to use a clearnet domain. Clearnet domains greatly reduce barriers to entry since they offer email-address like identities (for example, something@disobey.net), while still providing Tor network physical location metadata safety for all users. See more in RE3b below for more details. Clearnet domains allow operators to create identities and cultures around their relay, similair to how ActivityPub-based fediverse communities exit. For example, someone could use the clearnet domain "gay.paris", emphasizing a community centered on gay people in Paris. Users, of couse, can pick and choose any relay identity that they wish.

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 and federation.

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 (for example, disobey.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 (for example, something@disobey.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 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 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. However, client ephemeral public keys, not relayed to their Tor onion identity, will persist on relays forever, allowing clients to reclaim their prior user identity.

RE6. Clients connecting to this relay will be provided a current listing of other known Tor onion domains. These onion domains are client addresses or relay addresses.

RE6a. A client, with a list of other client addresses, will store the list of addresses for up to one month. This includes profiles that the user has "swiped left" or "swiped right" on, allowing a user to change their mind about someone else's profile.

RE6b. Other user's domain identities are not visible to users by deffualt. This is to minimize abuse. However, in either limited profiles or full pofiles (see CL0 below), users can opt-into sharing their clearnet or onion identities on their profiles.

RE6c. A client, with a list of relay addresses, will allow users to opt-into federating with other relays. Tor onion domains that are relay domains will be made clear in the UI, and if an associated clearnet domain exists for the Tor onion domain relay, the clearnet domain will become the emphasized domain in a client list, with an ability to see the associated Tor onion domain, and with an ability to opt-into federating with any number of known, online, relays.

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 CL0a - CL0c 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 CL0 below).

Private messages and private caches

PM1. The relay, in an end-to-end encrypted way, acts as a private message cache. Private messages are only ever possible after two or more people "swipe right" on the other, assuring mutual consent.

PM2. The relay will automatically purge private cache data after 28 days if no client downloads the private message. Relay operators can lower the maximum period of retention to not less than 7 days.

PM3. If clients come online and download their private messages, the client wipes the cached private messages from the relays.

PM4. Private messages can be text, media, or any file type, but limited to safe file types that the client app can reliably wipe file metadata. No file types will be supported if file metadata cannot be safely removed before sharing.

PM4a. Any user media added into to the client app, locally, must wipe all file metadata, before being end-to-end encrypted and shared with other users.

PM4b. Users have absolute control over what file types they consent to receiving. This way, users can automatically reject anything other than plain text.

PM5. Relays can set a max message size quota and will default to 1 MiB. This quota is per message, not per user. Relays are not aware of any metadata associted with messages or clients. These quotas will always be filled up to the quota size, filled by the client. This way, relays only ever see 1 MiB, end-to-end encrypted message data, attempting to lessen the risk of a malicious relay operator from at extracting message metadata.

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 engaged in private messaging. This way, users who are engaged in private messaging, will not be limited by file size quotas of their relay.

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

PM8. When clients come online, they will periodically check their relay's private cache for private messages. Also, for any consented connections from any time in the history of their profile, a client will periodically check the other relay's private cache for private messages, based on the identity of consenting matches or established private messages. 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 private cache.

PM9. If and when relays opt-into being globally federated (not just a community relay), in an end-to-end encrypted manner, private caches will federate with each other to help inform connecting clients of any private messages and automatically share end-to-end encrypted private messages belonging to the associated client of a consenting conversation. This way, if a client was able to store an outbound private message with one relay but not the other, based on consenting client relationships, private messages will federate to the associated relay. Therefore, private messages 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 CL0 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).

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 limited 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 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 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 mainly an issue if and when a relay has an associted clearnet domain, or if a publishing relay operator makes it clear who hosts a relay and from where.

RR2. If relay operators make themselves known, they also become a target of users who may think that the relay operator is responsible for their safety. Even if claims made against the relay operator are not based in facts, lawsuits can happen.

RR3. Storing private caches, even if limited to 1 MiB in file size, scales. An abusive client or clients may intentionally aim to fill your relay's private cache, possibly shutting down the relay.