Safebook is an experiment of a decentralized, uncensorable and unfalsifiable social network.
It is own and controlled by no other entity than the users. Fully peer-to-peer, no servers
It can connect people everywhere, with or without internet access, with or without states firewalls, surveillance, and could even go through the Great Firewall of China or to North Korea if a route is found (let's go libp2p!)
It enable hacktivist in internet-unfriendly countries to use it even with limitied internet connectivity
Unlike decentralized softwares like Matrix or Mastodon, and a fortiori centralized softwares like Whatsapp or Signal, Safebook is distributed and thus, has no single points of failure since the content is duplicated multiple times. (Censoring archlinux matrix user is still really easy, just block the dns archlinux.org or the associated ip...)
Local-area networking, without going through a central gateway, is enabled by default thanks to libp2p (think WLAN and Bluetooth). Offline fonctionnalities, and online reconciliation is possible thanks to IPFS
Data is never given to a third party. Data access is given by the owner only, every time, using cryptography.
You post something, you sign it. You hide something, you encrypt it. No server, only cryptography. Nobody can censor or temper with your data.
We take a novel approch to filter inappropriate and reported content: Since we're serverless, every client run the (eventually machine-learning based) filters and look if someone reported this content as inappropriate. (This is a vast subject, but should be done directly by the client)
Accounts are defined by a and address (ex: SBqViLJfdGaP4EeHnDyJbEGQysnCpwk3gd). It's a either pubkey or a pubky hash
It is similar to a phone number: You can give to someone so that it will be able to contact you and see your profile.
It is enough for decentralisation: Knowing the address allow everyone to authentify the user's messages and initiate a end-to-end encrypted connection with him.
The naive implementation of safebook addresses is pubkey hash with content on a ledger allowing GET service/${safebook_address} -> user manifest
user_manifest = { pubkey(=ecdsa_address), ecdh_address, ipns_address } + signature. safebook_address = OP_HASH160(pubkey)
A better implementation for safebook addresses would be a quantum resistant public key. The acount is thus self contained and is able - without server - to verify signed messages. A signed manifest is still required to be found on the network (or in an extended safebook address) for more advanced fonctionnalities like end-to-end encrypted messaging, IPNS, or cryptocoin addresses
We also support DDNS for usernames, ex: my profile could be as short as mjal.eth
Account generation and regeneration is defined by a password. No server-side data is required, everything is deterministically generated, providing natural serverless and multi-devices accounts. The password is NOT generated by the user.
We use a modify version of "hierarchical deterministic wallets"(BIP32) to generate all the keys and material
The password could be written in a piece of paper using a BIP39 wordlist or a QR-code, stored on a hardware device (think Trezor, even though we would need a custom firmware and a lot of dev for every fonctionnality and protocols we want to support) or stored on hard-drive or usb key (less secure). Extended data (encrypted informations) could be stored alongside or on a server (ex: for the password manager)
TLDR: The profile is a signed state compiled to a static webpage and stored on IPFS/IPNS
A safebook profile is a collection of a state (a key/value store, for every profile data like ecdh key, birthdate, links, etc and messages(including pictures)
Everything is signed by the user pubkey, either at the message level, page level, or at the IPNS level.
The safebook engine is at his core a static website generator to aggregate the state and the messages into a webpage for quick access, and for outsiders not using safebook. f(state) = page.html (theming is optional
To embed the state inside the webpage, we could use the semantic web, allowing a function f -> f(page) = state
Experiment: State as a CRDT signed hashchain of events (message events and state events) with data structure: { previous[], content{}, sig }
You can follow someone by signing his address. The web-of-followers and web-of-friends should follow the implementation of PGP web-of-trust.