seekia/documentation/Future-Plans.md

# Future Plans

The future of Seekia is full of possibilities.

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

## Before Launch

There are features and changes to be made before Seekia is ready for launch.

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

### Replace Account Credit with Merkle Tree Payment Proofs

Rather than using a central account credit server to fund content on the network, Seekia should use merkle-tree payment proofs.

A merkle tree payment proof provides a way to burn cryptocurrency funds in a single on-chain transaction for any quantity of identities, messages, reports, and profiles. Payment proof merkle trees enable a way to perform scalable proof-of-sacrifice/proof-of-burn.

Merkle tree payment proofs are needed to be able to support tens of thousands of payments per second, because creating an address and transaction to fund each piece of content and each identity would overload the blockchain(s) with too much on-chain data.

Payment proofs will be created and funded by Payment Proof Providers. These providers bundle payments from users into merkle trees.

Payment proof providers can be operated by anyone. They must be trusted not to log the payments made by each user. The Seekia admin(s) will share a list of trusted payment proof providers. Users will purchase cryptocurrency from them, which the providers will keep custody of. Payment proof providers can allow users to purchase custodied cryptocurrency via any payment method they desire, including bank transfers, credit cards, and cryptocurrency.

Payment proof providers may be required to register as exchanges/money transmitters, depending on their jurisdiction. Know Your Customer/Anti-money laundering laws may also be required to be obeyed in certain jurisdictions. A payment proof provider that does not allow any cryptocurrency to be withdrawn or traded may not be subject to these laws, as they are only allowing the user to purchase virtual custodied cryptocurrency. Similarly, online merchants which sell things for cryptocurrency are generally not required to get customer identification information, especially for small payment values. Payment proof providers can also make a profit from users by charging a small fee.

Payment proof providers will operate very similarly to [OpenTimestamps.org](https://www.opentimestamps.org) calendars. The major difference between them is that when using payment proof providers, users must pay to have their content included in the merkle tree. This requires payment proof providers to keep track of each user's balance, and provide a way for users to purchase custodied cryptocurrency.

If any of the payment proof providers are suddenly shut down, the payment proofs they created will still be valid. The users who purchased funds from them will lose any funds they had not already spent. The user's client will be able to switch to a new provider, and the user's balance will reset to 0.

A payment proof is a merkle tree path. The on-chain address for the payment proof is a hash of (The root of the merkle tree + A byte to represent the cryptocurrency). The cryptocurrency byte is included so that address is entirely different on each blockchain. The cryptocurrency value of each payment proof is calculated by dividing the amount of cryptocurrency initially sent to the merkle tree root's address by the number of layers between the root and the content's tree leaf node. Each leaf node is a hash of an identity hash, a profile hash, a message hash, or a report hash. A single merkle tree can contain multiple identical leaf nodes, allowing for each merkle tree to provide multiple payment proofs for the same piece of content/identity hash. A payment proof merkle tree can also be unbalanced, meaning that some leaves are closer to the root, and thus get to spend a larger portion of the total amount. For example, a 1 ETH merkle tree could distribute 0.5ETH to a top-level single leaf, 0.25ETH to a second-layer leaf, and 0.125 ETH to 2 third-level leaves.

The Seekia client will put scheduled user payments in a queue. The payment proof providers will wait for a certain time period to collect as many payments as possible, and then will combine them into a merkle tree and distribute the payment proofs to the users. The payment proofs are then broadcasted to the Seekia network by the users, along with the content that the proofs paid for. A single piece of content can be paid for with any quantity of payment proofs. There must be a minimum amount of cryptocurrency per payment proof to prevent spam.

Payment proofs allow the Seekia network to be fully decentralized, reducing the legal and technological attack surface of the Seekia network. Of course, nothing is "fully" decentralized, but at least there is no single server that the network relies upon.

### 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.

### More Encryption Methods

Add FrodoKEM, CSIDH, or both to encrypt network connections.

We don't need to add more encryption to messages, because that will increase their size, and we want to keep messages as small as possible.

We should add more encryption to network connections because doing so adds a very small amount of bandwidth when compared to the total request/response. The initial key handshake is only needed to establish the connection key, after which there is no speed/bandwidth difference.

The main consideration is the computational load of the encryption method on Hosts and servers, which may be too heavy for some kinds of post-quantum key encapsulation methods.

Someone should test FrodoKEM, CSIDH, Kyber, and Nacl to document and compare their speed and key sizes, and underlying cryptography. After this, we can make our decision on which method(s) to add. It is probably better to use 2 methods that use different cryptographic techniques (Isogeny/Lattice) rather than similar ones (Lattice1/Lattice2).

### 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.

## After Launch

The following describes ideas that can be implemented after the Seekia network is launched.

These ideas are a work in progress.

### 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 funded status of random profiles from the account credit servers and from hosts.

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

We should 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 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) is a free genomic data repository. OpenSNP relies on user submitted data, which can be falsified. OpenSNP 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 would enable genetic embryo selection on a much larger scale, 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. Even using a public model trained on closed data would not be sufficient for Seekia's use case, because we need users to be confident that the 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 a prediction of a prediction. 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/traits requires training data and access to genome wide association studies. Seekia 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'm still not sure 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 privates.

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. 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(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.

### Facial Similarity Analysis

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

This ability will be used in the racial 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 Racial 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 racial 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 would enable a more accurate search by relying on 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.

My 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 Kyber 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 calls. 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.

Seekia should also be able to download images of people who are racially similar to each user pair's calculated offspring using the same racial similarity calculation method already present in Seekia. This calculation includes comparing genes which influence traits such as skin color, eye color, hair color, and facial structure. The calculation also incorporates ancestral similarity.

To create this feature, we need many people to upload their genomes, ancestry composition results, and images of themselves to a database. Each participant must digitally consent to releasing this information into the public domain. The ancestral analyses can be provided by various companies and eventually Seekia.

Maybe OpenSNP.org could suffice as the database to use for this. User verification would be needed to prevent spam and fraudulent data from being used.

### WEBP Encoder

Someone should write a webp encoder in Golang.

This will allow us to stop relying on the libwebp C binding to encode WEBP images.

There are other people who desire this encoder as well.

Someone could also build a JPEG-XL encoder/decoder and Seekia could switch to that instead.

Other image encoding methods which utilize AI could be even more competent at compressing images.

### 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.