sarasova/seekia
sarasova/seekia
1
1
Fork 0
Code Issues Pull requests Projects Releases 2 Packages Activity

Improved Whitepaper.md and Future-Plans.md.

Browse source
This commit is contained in:
Simon Sarasova 2024-08-14 13:44:01 +00:00
parent 39c4edbe2f
commit 11f25c6c8e
No known key found for this signature in database
GPG key ID: EEDA4103C9C36944
4 changed files with 16 additions and 11 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
Changelog.md
View file

@ -6,6 +6,7 @@ Small and insignificant changes may not be included in this log.
## Unversioned Changes ## Unversioned Changes
* Improved Whitepaper.md and Future-Plans.md. - *Simon Sarasova*
* Created the GetUserGenomeLocusValuesMapFromProfile function and used it to remove some duplicated code. - *Simon Sarasova* * Created the GetUserGenomeLocusValuesMapFromProfile function and used it to remove some duplicated code. - *Simon Sarasova*
* Added new genetic attributes to the calculatedAttributes package. Added the ability to view and sort by these attributes in the GUI. - *Simon Sarasova* * Added new genetic attributes to the calculatedAttributes package. Added the ability to view and sort by these attributes in the GUI. - *Simon Sarasova*
* Upgraded Golang to version 1.23. - *Simon Sarasova* * Upgraded Golang to version 1.23. - *Simon Sarasova*

2
Contributors.md
View file

@ -9,4 +9,4 @@ Many other people have written code for modules which are imported by Seekia. Th
Name | Date Of First Commit | Number Of Commits Name | Date Of First Commit | Number Of Commits
--- | --- | --- --- | --- | ---
Simon Sarasova | June 13, 2023 | 282 Simon Sarasova | June 13, 2023 | 283

4
documentation/Future-Plans.md
View file

@ -19,7 +19,7 @@ A merkle tree payment proof provides a way to burn cryptocurrency funds in a sin
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. 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 will bundle many payments from many users into a single merkle tree. 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 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.
@ -29,7 +29,7 @@ Payment proof providers will operate very similarly to [OpenTimestamps.org](http
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. 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, or a message 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. 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. 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.

20
documentation/Whitepaper.md
View file

@ -124,7 +124,7 @@ Seekia is not reliant on proprietary mobile app stores. The Seekia application c
The genetic destiny of the human species should not be controlled by a small number of entities. Centralized mate discovery services can attempt to encourage certain kinds of relationships to form. For example, a nefarious mate discovery service could try to increase the prevalence of genetic disorders by encouraging relationships between people who have a higher probability of producing diseased offspring. The genetic destiny of the human species should not be controlled by a small number of entities. Centralized mate discovery services can attempt to encourage certain kinds of relationships to form. For example, a nefarious mate discovery service could try to increase the prevalence of genetic disorders by encouraging relationships between people who have a higher probability of producing diseased offspring.
The Seekia network strives to be open and decentralized. The Seekia network aims to be resilient in the event that any host suddenly stops participating or is compromised by bad actors. Seekia is not fully decentralized, because it relies on a central credit database to perform scalable private accounting. Seekia still reaps many benefits from its decentralized architecture. The Seekia network strives to be open and decentralized. The Seekia network aims to be resilient in the event that any host suddenly stops participating or is compromised by bad actors.
Anyone can participate as a network host, which involves serving profiles and messages to other network peers. It is impossible for a single host to prevent specific profiles and messages from reaching the rest of the network. Users broadcast and download content to and from multiple network hosts. Anyone can participate as a network host, which involves serving profiles and messages to other network peers. It is impossible for a single host to prevent specific profiles and messages from reaching the rest of the network. Users broadcast and download content to and from multiple network hosts.
@ -282,19 +282,23 @@ Without any form of spam prevention, a single malicious actor could spam the See
Seekia requires users to fund their identities before broadcasting content to the network. Users must also fund each message, report, and mate profile. Seekia requires users to fund their identities before broadcasting content to the network. Users must also fund each message, report, and mate profile.
In a fully decentralized model, users would use a cryptocurrency to fund each identity and piece of content. Cryptocurrency addresses would be derived from identity and content hashes. This approach requires using a decentralized cryptocurrency which can support tens of thousands of privacy-preserving transactions per second. I am not aware of any cryptocurrency which can support the necessary throughput, so a centralized accounting model is used instead. Users use cryptocurrency to fund each identity and piece of content. A simple way to accomplish this is to derive cryptocurrency addresses from identity and content hashes, and to send funds to these address to destroy coins. This strategy would require at least one cryptocurrency transaction to fund each identity and piece of content, which would limit the activity on the Seekia network to the scaling capabilities of the utilized cryptocurrencies.
### Account Credit ### Payment Proofs
A centralized account credit database is used to facilitate the funding of content and identities on the Seekia network. Payment proofs are used to enable the funding of many different identities and pieces of content in a single blockchain transaction.
Each account has a credit balance. An account is represented by a public/private key pair. Users must possess an account's private key to view and spend its balance. Credit can be purchased with cryptocurrency. Users can send credit from one account to another. A payment proof is a merkle tree path. A payment proof merkle tree is a bundle of cryptographic hashes. Each leaf node in the tree is a hash of an identity hash or a content hash. The on-chain address for each payment proof is derived from the merkle tree's root. The value of the cryptocurrency sent to each merkle tree's blockchain address is distributed among the tree's leaf nodes.
The database is trusted to not log user behavior. If a snapshot of the database were ever leaked, sensitive information such as the senders of messages would not be revealed. Payment proofs are created and funded by Payment Proof Providers. These providers bundle payments from users into merkle trees. Users can purchase virtual custodied cryptocurrency from each payment proof provider using cryptocurrency or other payment methods. Users use these funds to purchase payment proofs, which are broadcast to the Seekia network.
Using a central database allows for admins to freely create and distribute credit. Admins are able to onboard users to Seekia for free by sending them credit. A website could be created that allows users to receive credit by verifying ownership of a phone number. Phone numbers are costly for attackers to obtain. If any 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. User clients will be able to switch to a new provider, and user balances will reset to 0.
The account credit database is a single point of failure which the network relies upon. Creating backups of the database is prudent. If the database ever goes offline, hosts will continue to serve any content which has already been funded until the content expires from the network. Payment proofs also provide a privacy advantage. Blockchain transactions can often be traced. Without payment proofs, the addresses where funds originate for each transaction could be traceable, allowing observers to trivially identify which messages were sent by the same identity. Payment proof providers are able to break the link between the purchasing of account funds and the purchasing of payment proofs for their users.
Payment proof providers are trusted to not log user behavior. If a snapshot of a non-logging payment proof provider's database were ever leaked, sensitive information such as the senders of messages would not be revealed.
Payment proofs also function as timestamps. A payment proof proves that the funded identity or content existed at the time of the payment.
## Messaging ## Messaging