
# Future Plans

The future of Seekia is full of possibilities.

This document describes the currently planned and theorized features and changes to be made.

Many tasks are not included here, but are instead annotated within the code with the **TODO** keyword.

### Importing Profiles

If a user restores their identity on a new device, they will have the option of exporting/importing their user data folder to retain their data.

Their client should also try to download their broadcasted profile from the network.

If a profile exists, a GUI wizard should help them to import this profile, navigating any conflicts that exist between their local and downloaded profile.

A similar GUI wizard should also be used for the Import Data process.

### Whitespace Characters

Users should be prohibited from providing only-whitespace values in their profile attributes/ban reasons/etc. It is confusing for other users. We already restrict tabs/newlines for some attributes.

An example of only-whitespace is "   ", or "	"

There are multiple only-whitespace Unicode code points we need to detect.

We could instead use the GUI to replace all whitespace characters with a visible character if no non-whitespace characters are detected, without having to restrict this at the protocol level.

### True Location

Users could add a True Location to their client.
Users currently share a privacy-preserving location on their profile and in their criteria, which is near to their true location.
Adding a private true geographic location would enable mate distances to be more accurate.
This true location would never be shared, broadcast, or uploaded anywhere.

### Reject Duplicate and Excess MessagePack Keys

Currently, the msgpack decoder does not reject MessagePack that contains duplicate entries for the same key.

Here is an example in JSON to demonstrate this behavior:

`{"1":"A","2":"A","2":"B"}` would be read into a map like so: `1->A, 2->B`

The msgpack decoder also does not reject excess, ignored keys.
For example, if we unmarshal a MessagePack map with 5 keys into a struct with only 1 item, the 4 items will be ignored.

Someone could encode unruleful content inside of a piece of content without it being detected.

This would be fine for users who would never see this data, but could have legal consequences for hosts if the injected content was illegal.

We must detect this, by either using a different package, or seeing if the total bytes and matches the size of all unmarshalled values + the msgpack serialization overhead.

### Make Content Smaller

We can replace many Review/Report/Profile/Parameter attributes with a bytes encoding to make them smaller.

An example is replacing Verdicts with numbers during encoding to decrease size:

"Approve"/"Ban"/"None" -> 1/2/3

This is a task that is underway and partially completed.

### Connection Pool

See `internal/network/connectionPool.go`

### Trusted Hosts

The network parameters could share a list of trusted hosts.

These are hosts that are run by trusted members of the community, that will claim to not track users.

These hosts could be used to download data in bulk, where sharing information with the host becomes less risky.

An example is downloading message inboxes in bulk, allowing for much faster message downloading than downloading from each inbox over a fresh tor circuit.

### Moderate Over Clearnet Mode

Moderator over Clearnet mode would allow moderators to download content over clearnet rather than Tor.

This is similar to Host Over Clearnet mode. Many moderators will probably use this mode, especially moderators who are using VPNs.

### QR Codes

We need a way to generate Ethereum and Cardano address QR codes.

### Translations

We must add the `translate()` function everywhere it is missing within the GUI.

We must create a utility to find all calls to translation functions and build a list of terms that are needed.

We must create a list of translated terms for each supported language.

### Command Line Interface

We need a command line interface so users can deploy Seekia hosts on devices without using a GUI. This is essential for virtual private servers.

The command line should have an accompanied configuration file that is used to set the application settings.

### Ability for Admins to Gift Identity Score

The network parameters could allow admins to gift Identity Score to specific moderators.

The parameters would contain a map of Identity Hash -> Amount to gift

This would function as a more decentralized version of Supermoderators, where moderators that the admins trust are given score based on how trusted they are.

Another use would be to help moderators recover their scores if their identity keys get compromised or lost. This would require moderators to prove their new identity, either via their real-world identity or an older key that was signed by the moderator's key before it was compromised/lost.

This feature might not be worth adding.

### Public Desires

Mate profiles should have a Public Desires attribute, which can be used to describe what they desire in a mate. This would be a text attribute.

Another feature would be allowing users to share numerical desires such as minimum/maximum values. Other users could filter users with the desire "I Fulfill Their Desires". After much consideration, I am generally against adding this feature, because user desires are flexible and constantly changing, and most desires are probably embarrassing to share publicly.

Additionally, many users will be able to infer that another user will probably not be interested in them and will not bother to pursue them. We should add more written desire attributes to accomplish this, without having to define quantitative values such as minimum/maximum age.

### New Logo

The current logo needs a redesign.

The new logo should be more symmetric and visually appealing. A more intricate design would look nice.

If someone could come up with a novel design, that could also be adopted.

### Mate Mode

We need a way to disable/enable Mate mode.

When Mate mode is disabled, a user's client will not download profiles to browse. Mate mode should be disabled when the application is first started.

We also need the user to choose some basic desires and download desires before we start downloading profiles. Otherwise, the application will attempt to download all viewable Mate profiles. Age, Sex, and Distance should be enabled as download desires when a user is first created.

### Adjust Allowed Space On First Startup

Users should choose the amount of space Seekia can use on first startup.

Another option would be to set Seekia to use 10% of the free disk space upon first startup.

We need to make an easy to see warning when a user's allowed disk space has been used up.

We should add an Alerts section on the home page, which can be used for these kinds of messages.

### Desires Pruning Mode

If no space is left, and user is in Mate mode, we should enter desires pruning mode.

When this mode is enabled, we will delete profiles that do not fulfill our desires in an effort to save space.

When the mode is disabled, we only delete profiles that do not fulfill our criteria.

We need to create jobs to check for this condition and prune profiles which do not fulfill our desires.

### Suspicious Hosts

The app should maintain a list of Malicious hosts and Suspicious hosts.

A suspicious host is a host that is probably acting in a malicious manner, but might not be.

An example is a host who serves different Viewable statuses than other hosts. If they have a track record of doing this, they are probably lying. They could also have a slow network connection.

Users should avoid suspicious hosts, but maybe still contact them occasionally.

### Busy Hosts

Hosts can respond to requests with a Busy response.

A package called `busyHosts` should be created to keep track of busy hosts.

User clients will avoid these hosts until they are automatically removed from the busyHosts list after a defined wait time duration.

### Statistics Range

The current limitation of the Seekia app's statistics is that they will only represent the statistics for profiles that the user has downloaded. Most users will download a subset of total profiles which are already filtered by their downloads desires. Desire statistics are still a valuable tool for users, but they will not usually reflect an accurate view of the statistics of all users.

The solution is for the Seekia app to download a set of random profiles to use for generating statistics about all network users. Each user's app should have a statistics range, which is a randomly-selected identity hash range. The user's app will make requests to download all profiles for users within this range. The range should expand and contract to contain a certain number of profiles, such as 500 or 1000.

Each user's statistics range will create an identifiable fingerprint when they make certain requests. This fingerprint must be hidden properly to preserve each user's privacy. Requests to download and update the profiles within a statistics range should be sent on their own and over unique Tor circuits.

### Tor Client

Someone should build a Tor client in Golang. We define a Tor client as a piece of software which can query the Tor network for node information, choose a path of nodes for a request, craft requests, and send requests. The initial Tor client implementation only needs to support making requests over exit nodes onto the clearnet. Building a Tor client should not be nearly as difficult as building a full Tor node, which would require implementing request routing logic, node information broadcasting, hidden service support, and various other functions.

A Tor client written in Golang would likely be used by many other projects. The Tor client I described could replace the main Tor implementation for applications and use cases which only rely on Tor to anonymize traffic over exit nodes.

### Banning Malicious Hosts

Moderators should automatically ban any hosts who seed them invalid information.

An example of misbehavior is providing identities/inboxes outside of the requested range.

Moderators could make requests to hosts to audit them.

If the hosts provide invalid information, the moderators can automatically ban them.

An example: Moderators can get the address deposits of random addresses from their own local blockchain node and from hosts.

We can do this with other kinds of requests to catch and ban bad hosts automatically.

We must avoid doing this for information where the host could be accidentally incorrect. Examples of this kind of information are viewable statuses, which could be wrong if the host does not have an accurate view of the network.

### Add Blood Type

Seekia could include blood types in user profiles. People could use this information to choose a mate whose blood type would have the highest likelihood of a healthy offspring. An example is to convey the risk of Rh Disease. There are probably other ailments whose risk could be reduced by preventing couples with certain blood types from having children with each other.

Blood type is a very complex topic, as there are hundreds of different antigens that determine someone's blood type. More research is needed on this topic.

### Other Genetic Compatibility

Other genetic based dating services like GenePartner claim to be able to match people based on their HLA genes.

The reasoning is that pairing people based on their HLA genes will result in children who have healthier immune systems. The human body naturally does this by being attracted to the scents of people who have immunity genes that are advantageous to the offspring.

Once we use neural networks to predict offspring polygenic scores, we should be able to detect many complex gene interactions, including HLA genes. If we train a neural net to predict a person's general immune system health, we should include HLA genes in the input genes.

There is a lot of potential for genetic compatibility testing that extends beyond monogenic and polygenic disease and trait analysis.

There is still value in investigating other kinds of genetic compatibility that we would not be able to detect in the predicted offspring's genome. For example, more research could be done on human scents. There might be a way to detect what kinds of scents someone will be attracted to and produce from their genome. We could add this functionality into the application, so users can see whose scents they are more likely to be attracted to.

### Kinship Analysis

Seekia needs to be able to calculate kinship between two people's genomes. This will be useful to prevent accidental inbreeding.

Many open source software packages exist that can calculate kinship. Use these as your guide to build the feature.

If it is possible, users should upload portions of their genome to their profiles which are sufficient enough to determine how related they are to other users, so users can screen out too-related users before even meeting them. If we want to keep user profiles below a few megabytes, this might not be possible. Many users may also be wary of sharing large portions of their genome in their profile.

At the very least, users should be able to calculate kinship by using the Seekia application offline. They could even send their genome files over the internet to perform the analysis before meeting in person.

### Inbreeding (Parent Relatedness)

The Seekia app should also be able to calculate how inbred a person is from their genome. The user should be able to display this value in their profile.

### Ancestral Analysis

The Seekia application should be able to perform its own ancestral analysis.

There could be several analysis methods. These analysis methods will serve as an alternative to company-provided analyses.

Providing an open source ancestral analysis method is essential for ancestry aware mate discovery technology to be credibly neutral. There already exist multiple open source ancestral analysis packages.

### Add Complex Disease Diagnosis

Many genetic diseases are not able to be detected using the methods implemented in the `monogenicDiseases` or the `polygenicDiseases` packages.

Examples include diseases such as Fragile X and Turner's Syndrome.

A new format called `complexDiseases` could be created.

Each disease can have a function that takes in a genome map and returns a diagnosis.

The GUI would also have an accompanying set of pages to display complex diseases.

### Add Polygenic Disease Probability Risk

We want to calculate an adjusted probability that the person will become victim to a polygenic disease.

Meaning, we want to tell the user the estimated probability that they will get a particular polygenic disease, for each age period of their life.

Example: Normal risk = 5%, Your risk = 10%

This will be the most useful statistic for users trying to understand their polygenic disease risk.

Knowing that your risk score for a particular type of cancer is 10/10 is much less useful than understanding your probability of getting the cancer.

If the general population probability of getting cancer X is 5%, and the user's adjusted risk is 50%, that is a significant increase. However, if the general population risk is 0.1%, and the user's adjusted risk is 1%, then the user does not need to change their behavior or worry much.

### Get More Genetic Training Data

We use neural networks to predict traits and polygenic diseases. We have to train these networks using example training data. This training data is a collection of people's genomes and the trait/polygenic disease information for each person.

Good training data is largely unavailable for public use. We need fully open training data, not data that requires registration or permission to download.

[OpenSNP.org](https://opensnp.org) was a free genomic data repository. OpenSNP relied on user submitted data, which can be falsified. A future online genetic biobank should add a verification system so data provided by trustworthy people can be prioritized.

More people should create public domain genome banks. If they had multiple locations surveying and sequencing people every day, they could sequence tens of thousands of people a year. This data would quickly be sufficient to train the neural nets to predict attributes with some accuracy. Each participant would have to sign an agreement to release their response and genome into the public domain.

Whoever collects the data needs to choose what data to collect from each person. The more information collected, the more genetic prediction tests can be made.

Some examples of data to collect:

* Collecting polygenic disease information enables prediction of polygenic disease risk.
* Pictures and scans of participants faces would enable a genetic test for facial structure
* Personality tests would enable prediction of personality
* Measuring height enables prediction of height

These kinds of genetic tests would allow parents to choose what their offspring will look like, their personality, and their intelligence.

Another option is for a wealthy entity to purchase an existing biobank and release the data into the public. They would have to send consent forms to the people whose genomes have already been analyzed, even offering to pay them to release their genome and response data into the public domain. Participants could opt to withhold some of the information, and also augment their data by taking more tests. This approach would avoid the need to sequence large numbers of genomes again.

Many organizations and individuals would be willing to fund this endeavor. Open source genome prediction technology can enable more informative genetic embryo selection, reducing global rates of disease, increasing human intelligence, and improving all aspects of people's lives. It would be a tremendously altruistic technology to help humanity. The increase in human intelligence alone would significantly reduce poverty, crime, irrationality, and many other challenges facing humanity.

There are many benefits to having widely available open source genetic prediction technology. People will be able to predict what diseases they are likely to have and prepare accordingly. People will be able to satisfy their own curiosity about how tall they could have been if they had sufficient nutrition and sleep. Parents who are adopting children whom are already born could choose to adopt children whom will have a similar personality and intelligence to themselves. This could increase people's willingness to adopt. People with lower disease risk will have a higher sexual market value, and can convey that risk in their Seekia profiles.

All of this is already possible, but will become easier with the proliferation of more advanced open source genetic prediction models. Many advanced genetic prediction methods already exist, but many of them are closed source. Using a public model trained on closed data is not ideal for Seekia, because we want users to be confident that the prediction models are reproducible and created from accurate data. We want the genetic future of the human species to be steered by open source technology.

We can create training data by taking freely available genetic biobanks which lack phenotype data and using freely available prediction scoring methods to infer the likelihood of each phenotype for each genome. See [pgscatalog.org](https://www.pgscatalog.org/) for polygenic scoring methods. This strategy would be inferior to having the original biobank data because we would be trusting the people who provided the polygenic scoring methods, and predictions would be less accurate because we would be training on predicted data rather than the true disease/trait values. This strategy will likely be necessary because it will allow us to circumvent gaining access to biobank data.

### Add more diseases and traits

Adding monogenic diseases entails entering disease SNP data from SNPedia.com and other sources. The bases have to be flipped if the orientation on SNPedia is minus. This requires flipping G/C and A/T. At least 3 people should check any added disease SNPs to ensure accuracy.

This is a tedious data entry process with negative consequences if mistakes are made. Many users could falsely believe they have monogenic diseases, which could trigger mental health crises.

Adding polygenic diseases and traits requires training data and access to genome wide association studies. Seekia's Create Genetic Models utility should also have the ability to perform genome wide association studies to find causal genes for traits.

### Interactive Map

Seekia should have an interactive world map. It would be similar to OpenStreetMaps, but with much less detail. It would only need to contain borders of countries and states as lines. It would be able to display latitude/longitude coordinates on the map as points.

The map would be useful for many reasons. Users could view other Seekia users on a map. Users whose city is not included in the cities dataset could use the map to visually choose a coordinate point close to their own, rather than having to use a website such as Google Maps. Some statistics could be viewed in map form by coloring in different areas of the map based on the geographic distribution of certain attributes.

The map would contain all of its needed data offline. The graphics outlining the world's continents, countries, and states would be small enough to be included with every Seekia download. We will be able to overlay the city names in the already included cities dataset to make the map even more useful.

Someone has already built an Open Street Maps explorer for Fyne. That could be useful for someone who builds this. It is located here: [github.com/fyne-io/fyne-x](https://github.com/fyne-io/fyne-x)

There exist many free vector world maps that can be used for this.

### Private Information Retrieval

Seekia could use a private information retrieval scheme when users query hosts.

This would enable users to only download the profiles that fulfill their desires, without hosts learning their private desires or which profiles they downloaded. This would enable users to download fewer profiles, by using their private desires when downloading profiles. Users could also request messages from multiple inboxes in the same request, greatly reducing the number of hosts they must request from.

I'm not sure if this is theoretically possible, or if the required data to download would be so large that it would be slower than using our current methods.

A simple example of private information retrieval:

1. The user wants to download a single profile privately.
2. They request that profile, and 100 decoy profiles from host A.
3. Host A XORs the profiles together and sends the result to the user.
4. The user then requests from host B the 100 decoy profiles.
5. Host B XORs the 100 decoy profiles and sends the result to the user.
6. The user XORs the responses from Host A and Host B and is left with the profile they desire.

Each profile has to be padded to the same size for this to work. The advantage to this method is that only 2 profiles worth of bandwidth have to be downloaded, without either host knowing which profile the user requested. This only provides privacy if host A and B are not colluding.

A better method may be possible with homomorphic encryption. The Spiral PIR scheme is already enabling this sort of querying of address balances within the bitcoin blockchain. I don't know if this could actually work to increase privacy, reduce download speeds, and save bandwidth within the context of Seekia.

### Neural Network Detection Of Unruleful Content

Seekia could have a neural network built in to alert recipients of unruleful images within messages.

The neural network could give warning to the recipient before viewing content. Bumble has created the Private Detector, a neural network which detects images of a man's genitals.

Seekia already uses a slow reveal in the GUI, which slowly depixelates the image, so this kind of detection may not be desired by recipients.

Neural network detection would be more useful for moderators. We could eventually rely more heavily on neural network detection for moderation.

This might be easily defeatable by editing individual pixels in the offending image, or individual characters in text, until they pass the neural net filter. The neural nets should not be relied upon to approve or ban content.

#### Zero Knowledge Proof Of Ruleful Content

Messages could contain a zero knowledge proof that the contents of the message have passed a neural network that detects for unruleful content.

This is difficult because the messages are encrypted. The zero knowledge proof would have to prove that the encrypted content has passed the neural network filter(s).

This would give more peace of mind for hosts, who would have a much higher level of confidence that that are not hosting unruleful content.

### Web Explorer

Someone should build a web explorer for the Seekia network.

Anyone could use this website to browse users without having to download the Seekia application.

If they want to create an identity, they should download the Seekia application. I am generally against creating a website that allows users to create an identity and communicate with users. Users would have to trust that the website operator is not tracking their activity. At least with the Seekia application, users can compile from source or trust reproducible builds which are signed by multiple people. Centralized website clients do not provide the full benefits of decentralization and trustlessness.

### Facial Similarity Analysis

Seekia should have the ability to analyze user photos and calculate facial similarity.

This ability will be used in the deep appearance similarity analysis for facial structure.

#### Reverse Person Search

Users should be able to import photos, genomes, and physical characteristics for people they are attracted to and sort users by their Deep Appearance Similarity to these people. For example, if someone becomes infatuated with a celebrity, they can import the celebrity's genome, eye color, skin color, hair color, and hair texture into the Seekia app and sort their matches by their deep appearance similarity to the celebrity.

Users should be able to include this information in their criteria to hosts.

Someone should create a service that allows users to perform this search without having to download the Seekia app. There are already websites that allow people to find their doppelganger with photos. The Seekia network could enable a more accurate search by additionally utilizing genetic data.

### Video and Voice Communication

Users should be able to communicate via video and voice chat.

Many video and voice chat apps work by creating a direct connection between two user machines. The problem with this approach is that both users will see each other's IP addresses.

Using the Tor network to shield each user's IP address is too slow. Session messenger offers onion-routed video communication over Lokinet, but onion routing voice calls is probably still too slow and unreliable for use in Seekia.

A solution is to use trusted call coordination servers. The only purpose of these servers should be to connect calls between two users and pass packets back and forth. Each user's Seekia identity does not need to be shared with the servers. The servers should only learn which IP addresses are communicating and for how long. Users using a VPN will be able to protect their true IP address from the coordination servers.

All communication should be encrypted using multiple technologies such as Mlkem and Nacl. The packets should be signed with ephemeral identity keys which the users exchange in their messages, so man-in-the-middle attacks are not possible. The key handshake would occur between the conversation parties, so the coordination server cannot decrypt the conversation packets.

These servers should be run by trusted entities, and their domain names and signing keys should be listed in the network parameters.

Users should be able to send files through an encrypted one-hop connection. This way, users can send their genomes through a secure channel without having to meet in person.

### Offspring Appearance Prediction

Users of Seekia should be able to understand what their offspring with each potential mate is likely to look like. This is useful when deciding who to mate with.

Seekia should generate many prospective offspring images by using both user's photos, ancestry, and trait information. A service called BabyAC exists which creates a prospective baby image from images of both parents (see [Baby-AC.com](https://baby-ac.com/en)). Seekia should predict an adult appearance.

### Better Image Format

Currently, Seekia encodes user images in the JPEG format.

There are better image formats which produce smaller images, such as webp, jpegxl, and advanced AI-based image formats.

An example of an AI-based image encoding format is [TiTok](https://yucornetto.github.io/projects/titok.html).

AI-based image encoding formats are capable of producing the smallest images.

If someone can build a Golang package which encodes/decodes images into a better image format, Seekia should switch to using it.

Alternative image format Go packages do exist, but most rely on binding to C libraries. I want a pure Go implementation.

### Compromised Keys List

Some user identity private keys will be hacked. Once a private key is hacked, it can be used to impersonate a user.

Users should be able to share their compromised private key to the network, allowing those identities to be banned from the network. Once shared, these identities would not be able to participate in the network, send messages, etc. The announcement that contains the compromised private key should be hosted by the network until the identity expires. For funded moderator identities, they must be hosted forever.

## Conclusion

Thank you for reading this document. Please share your ideas on ways that we can further improve Seekia.

