You might be interested in my thoughts on redesigning the core of the protocol

quoting
naddr1qv…ne0u

“Do one thing, and do it well.” -Tux the penguin

Reading this lexicon should help you envision my overall concept much better than if I actually tried to explain it as an overall concept. I’m still not sure if this is worth reading for anyone so I’m working on making a nice roadmap presentation out of it, with more detail, even though I’m not a coder and it might never get made.

Here’s a turtle emoji as a pre-emptive apology for me reacting defensively to feedback 🐢

New nevents

We don’t use English or any particular human language in the code for nevents anymore (the actual nevents themselves, protocol doesn’t care how you implement). Kind 1 events now have language tags, version letters supporting up to 25 edits, and some other metadata. All of this is encoded with a more efficient and unbiased binary structure instead of using labels based on the English language (which would be a waste of binary bits for users who don’t want to learn English).

Legacy nevent: the old nevents.

Core suite

A suite including reference examples of tools listed here.

Components of the nostr

New relay: a program which sends and receives requests and responses over an interface such as a networking protocol. Has its own keypair. Has its own index of other relays, their keypairs, and how to reach them (can optionally index relays it’s not compatible with). Can be configured to respond on its own to requests for relay information from its index, but otherwise just sends and receives blindly.

Legacy relay: the old relays full of legacy nevents.

Keygen: tools like Rana which generate keys or keypairs.

Nevent publisher: runs on same system as a relay, checks if non-delete nevents are valid and offers to broadcast.

Nevent author: generates valid nevents other than deletes.

Deletion generator: generates deletion requests.

Nevent deleter: runs on same system as a relay, checks if a deletion request is valid and offers to broadcast.

Nevent inspector: runs on same system as a relay, monitors the relay for incoming nevents, checks if nevents are valid nevents from whitelisted pubkeys. Reports bad copies, which are 2 different versions of an nevent with the same ID and version letter and valid signatures from the same author. Pairs of bad copies are sent out when identified so the post can be flagged for having 2 concurrent versions.

Whitelister: accepts invite codes to add pubkeys to the inspector’s whitelist. Generates invite codes for users. Can accepts donations, generating invite codes for donors.

Blacklister: can monitor relay traffic and library index and modify the inspector’s whitelist and blacklist. Useful for blocking spam and setting a limited number of nevents/requests before renewal is required for a given pubkey.

Nevent library: runs on same system as nevent inspector, saves the valid nevents it receives. Indexes nevents by event ID, timestamp, and version letter. Queries are answered at localhost or over the relay. Doesn’t know other shit about its nevents, not even what pubkey they’re from. Indexer is usually present to handle further indexing.

Nevent indexer: runs on same system as nevent library. Crawls nevent contents, does additional indexing based on customizable parameters like pubkey, hashtags, and other search terms. Handles specific requests and queries at localhost. Default configuration just indexes nevents by pubkey and has searching of text contents disabled.

Nevent librarian: runs on same system as a relay, nevent library, and nevent index. Monitors its relay for index requests, optionally checking if signed by a whitelisted pubkey before returning results from the index.

Library janitor: runs on same system as a library, removes lowest-priority nevents to clear storage space. Can replace limiting role of blacklister by scaling allowed nevents to donation size for each inspecror-whitelisted pubkey.

Nevent seeker: runs on same system as a relay, sends queries to librarians.

Vapor feed: a feed made of remote query results from a seeker running on the same system and connecting remotely to a librarian.

Liquid feed: a feed made of local query results from an indexer or archivist running on the same system.

Feed reader: stores a list of queries with optional labels and notes about them, and fetches kind 1 only posts matching the queries through a seeker or indexer or archivist. Following someone is done by listing their pubkey for querying. Reference implementation doesn’t support kind 0, user-defined names and notes for followed pubkeys are expected. Reference implementation only supports querying pubkeys and hashtags but other implementations can do whatever kind of queries will be accepted by their seekers/indexers/archivists.

Profile reader: separate tool for kind 0 queries. Most implementations will want to just bundle this functionality in the feed reader, but the reference implementation should keep them separate.

Nevent archivist: can back up nevents from relays. Can back up nevents and/or indexes from libraries and/or indexers and/or other archivists.

Nevent converter: connects to legacy relays. Converts nevents to and from legacy format. Sends results where configured to. Can run on same system as a legacy relay, or connect remotely.

Web server: can optionally serve HTML-only (JavaScript-free) versions of other tools in the suite. For example, it can load an HTML page with a keygen frontend; or a frontend for the whitelister, offering invite codes for completing a captcha; or a nevent author frontend combined with a nevent publisher with built-in relay functionality connected to the server (where the server’s nevent inspector is applied).

Other essential core suite tools

Sig checker: very tiny minimalist command-line tools for checking different kinds of hashes and signatures. Each focused on one method of functionality.

Encryption codec: very tiny minimalist command-line tools for encrypting and decrypting data. Each focused on one encryption algorithm, usually text encryption. Private messages are low-discoverability kind 1 nevents including encrypted text which needs to be converted using one of these (and hopefully also including unencrypted instructions by default).

Blockchain scanner: scans a blockchain network for transactions to a given wallet.

Cryptocurrency transaction generator: signs cryptocurrency transactions.

Cryptocurrency transaction transmitter: transmits signed cryptocurrency transactions to network nodes.

Cryptographic verifier: very tiny minimalist command-line tools for teaching the user how to use a calculator or pen and paper to perform the functions of sig checkers and encryption codecs, and perhaps other cryptographic functions. Requires at least one sig checker and at least one encryption codec in the suite to be feasible for using by hand with pen and paper, at least enough to check if electronics seem to be working as intended.

QR code generator: generates QR codes, which can be used as a data transmission protocol humans are able to monitor (faster but not excessively less secure than copying text by hand to and from an air-gapped system).