james-munns.frauth

FRAUTH-CONTENTS
name = "James Munns"
note = "Hello, I'm James!"
pubkey = "💥💿🍞🔫☕️👽🔍👶🐣👉🏃💫⚓️👑🐸🍏🐾🐊🍎🎺💯💻💦🍸🐒👑🍼⚓️💔🏆🎬⛔️"

[identities]
email = "[email protected]"
github = "https://github.com/jamesmunns"
twitter = "https://twitter.com/bitshiftmask"

[[friends]]
name = "Alice Shamir"
uri = "https://example.com/.well-known/alice-shamir.frauth"
pubkey = "✈️🐖💤📼🎁🍬🍕🚀🔕💨🔗🎸🚽🐬📚🐨🔬🐩👜🔆🎻🎷⛳️💣👢🐫💰☕️🐛👣🏊‼️"

[[friends]]
name = "Bob Diffie"
uri = "https://beispiel.com/.well-known/bob-diffie.frauth"
pubkey = "🚨🎨💃🎨🐀👐➡️🎤🎄🌀🎃🐄👆👫🍷🐸😠😠🌙🌳🔮🐔🏃💐🍟🌿⌚️🐨💪🍐🎊👉"

FRAUTH-SIGNATURE
🌵⛳️🎍👢🔆🔗👏⬅️🐖🐬🐓🔋⬅️👃🍫💻💧🐄👎🐼✂️🏃💍🍺💪⚓️🔆👢🍰💻💊🚴🐇🚀🐻🐺🌵⬇️🐍👊⬅️👍🍨🍸⌚️😎🔦🐋📻🍒💔🌼🐎🎁👍👅📻🎳👃🏀🐙🔆👔💢
FRAUTH-ENDOFFILE

The idea is to build a "web of trust" from verified friends, and their verified friends. The tool should not report a binary trust, but instead display a weighted value based on their distance (so a direct trusted friend is 1.00, a friend of a friend would be less, and a friend of a friend of a friend would be even less).

The hope is to have a distributed and peer-to-peer solution for problems currently solved by gpg (and associated registries) as well as services such as keybase.

This tool does not aim to have configuration around encryption options, to reduce complexity. Currently ed25519/edDSA is used for all functionality. Future versions of the tool may include semantic versioning of files, allowing for a limited amount of backwards compatibility.

Long term goals

• A CLI tool will be able to spider the web of trust, to some configurable depth, caching the results locally.
• A CLI tool will be able to periodically update the cached results, notifying the user on changes, and removing verified contacts if details have changed.
• A CLI tool can notify when identity changes, or when new items can be imported to the web of trust
• A CLI tool can display an "address book" based on this web of trust
• A CLI tool will be able to encrypt a message to a given person using their verified (or web of trust known) public key by using their ed25519 public key for EdDSA asymmetric encryption. The recipient of this message can verify this message using the CLI tool.
  • TODO: Verify if this is sound?
  • TODO: Sign message with own private key inside or outside of encrypted message?
• A CLI tool will be able to sign a given message, using own private key. Recipients will be able to verify this message using the CLI tool.
• Very very long term: Ability to sign/verify git commits using frauth data?