urras / toxiddraft

Brainstorm for Tox username/password implementation

ToxIDDraft

Brainstorm for Tox username/password implementation. If you stumbled here expecting to find some revolutionary implementation, please leave.

• Custom usernames
• Custom and changable passwords
• Password/username recovery options
• Use username and password on multiple devices
• Ability to login and register within client (much like Antox or GSOC-1).
• Trustless distributed database that does not use a blockchain (does not currently exist)

##Screenshot ###Login Window:

###Registration Page:

toxiddraft's Issues

Namecoin as basis for distributed identity store

Namecoin already has /id for handling public identities, this could be coupled with a hashing algorithm to create a unique ID that by itself cannot be used to identify a user's tox account(s).

https://wiki.namecoin.info/?title=Identity

Brainstorming for possible specifications

Distributed ID store requirements:

Must remain small and workable for low powered platforms e.g. smartphones
Must not at all exchange private keys
Must be easy to use
May not share public keys publicly?

With multiple accounts we assume:
Each device can have its own Tox ID or multiple IDs, an account can be comprised of multiple linked and unlinked IDs

How Linked ID's might be handled by clients:
When a user is linking two of their own devices or IDs to the same account, public keys are exchanged between devices, all user’s own public keys are kept in sync across devices.
If a user removes a device or ID from their linked list, all of their clients and their friends are automatically notified as they come online and ID lists are automatically synced and modified accordingly.
When adding a friend, all of their linked public IDs will be sent and represented as a single user by the client.

Possible solutions to distributed, trustless database:

• A temporary trustless database hosted on Tahoe-LAFS or FreeSQL with tokens that expire after a short time period e.g. 24hrs. Entries are locked with a ‘secret key’ that is created by the user who initiates a ‘broadcast’ (putting a temporary ID on the public ledger), once the user completes the exchange, they are shown how long their token is valid for, and then given the option to expire it now with their secret key, or to let it span the maximum duration.
  Issues: DB on Tahoe might be too large and complex for a simple solution, FreeSQL relies on Freenet and is also unmaintained
• A blockchain model (possibly verified with Proof of Burn where spent tokens or expired tokens are burned to verify the blockchain, or a very simple Proof of Work.)
  Issues: Not able to determine whether a blockchain with expired tokens and limiting recorded transaction history to a shorter range e.g. 24hrs is possible.

Key sharing:
User must exchange keys in an easy fashion.
Possible solution:
Represent temporary token as a memorable passphrase e.g. a dictionary word with a 4-5 digit number and letter combination, randomly distributed at the start and end of the word.

Unlicense is not valid in countries that don't recognise the Public Domain as an entity

Unlicense and other public domain dedications are not valid in countries such as Germany or Australia as PD works are based on the absence of copyright, and in those jurisdictions copyright cannot be waived.

CC0 takes this into account and will allow people in all jurisdictions to use either the PD work or one under a very close liberal license.