small revisions to spec and add in some more structure, and gitignore

.gitignore

@@ -1,25 +1,80 @@
-# If you prefer the allow list template instead of the deny list, see community template:
-# https://github.com/github/gitignore/blob/main/community/Golang/Go.AllowList.gitignore
-#
-# Binaries for programs and plugins
-*.exe
-*.exe~
-*.dll
-*.so
-*.dylib
+# Ignore everything
+*
 
-# Test binary, built with `go test -c`
-*.test
+# Especially these
+.vscode
+.vscode/
+.vscode/**
+**/.vscode
+**/.vscode/**
+.idea
+.idea/*
+.idea/**
+**/.idea
+**/.idea/*
+**/.idea/**
+node_modules
+node_modules/
+node_modules/**
+**/node_modules
+**/node_modules/
+**/node_modules/**
+**/target
+**/target/
+**/target/**
+target
+target/
+target/**
+key
 
-# Output of the go coverage tool, specifically when used with LiteIDE
-*.out
-
-# Dependency directories (remove the comment below to include it)
-# vendor/
-
-# Go workspace file
-go.work
-go.work.sum
-
-# env file
+# others
 .env
+/.idea/.gitignore
+/.idea/material_theme_project_new.xml
+/.idea/modules.xml
+/.idea/protocol.realy.lol.iml
+/.idea/vcs.xml
+
+# But not these files...
+!/.gitignore
+!*.go
+!go.sum
+!go.mod
+!*.md
+!LICENSE
+!*.sh
+!Makefile
+!*.json
+!*.pdf
+!*.csv
+!*.py
+!*.mediawiki
+!*.did
+!*.rs
+!*.toml
+!*.file
+!.gitkeep
+!pkg/eth/**
+!*.h
+!*.c
+!*.proto
+!bundleData
+!*.item
+!*.bin
+!*.yml
+!*.tmpl
+!*.s
+!*.asm
+!.gitmodules
+!*.txt
+!*.sum
+!version
+!*.service
+!*.benc
+!*.png
+!.openapi-generator-ignore
+!.gitignore
+!*.jsonl
+
+# ...even if they are in subdirectories
+!*/

README.md

@@ -6,4 +6,7 @@ Inspired by the event bus architecture of [nostr](https://github.com/nostr-proto
 
 - [why](./why.md)
 - [event spec](./spec.md)
-  
+- [matrix chat](https://matrix.to/#/#realy-general:matrix.org)
+- [reference relays](./relays/readme.md)
+- [reference clients](./clients/readme.md)
+- [GO libraries](./pkg/readme.md)

clients/readme.md

@@ -0,0 +1,3 @@
+# clients
+
+here be some reference clients for various sub-protocols

pkg/readme.md

@@ -0,0 +1,3 @@
+# pkg
+
+go libraries shared by clients and relays

relays/readme.md

@@ -0,0 +1,3 @@
+# relays
+
+relay implementations for various subprotocols

spec.md

@@ -2,7 +2,7 @@
 
 JSON is awful, and space inefficient, and complex to parse due to its intolerance of terminal commas and annoying to work with because of its retarded, multi-standards of string escaping.
 
-Line structured documents are much more readily amenable to human reading and editing, and `\n` is more efficient than `","` as an item separator. Data structures can be much more simply expressed in a similar way as how they are in programming languages.
+Line structured documents are much more readily amenable to human reading and editing, and `\n`/`;`/`:` is more efficient than `","` as an item separator. Data structures can be much more simply expressed in a similar way as how they are in programming languages.
 
 It is one of the guiding principles of the Unix philosophy to keep data in plain text, human readable format wherever possible, forcing the interposition of a parser just for humans to read the data adds extra brittleness to a protocol.
 
@@ -10,10 +10,16 @@ So, this is how realy events look:
 
 ```
 <type name>\n
-<pubkey>\n
+<pubkey>\n // encoded in URL-base64
 <unix second precision timestamp in decimal ascii>\n
-key;value;extra;...\n // zero or more line separated, fields cannot contain a semicolon, end with newline instead of semicolon
-content // literally this word on one line
-<content>\n
-<bip-340 schnorr signature encoded in base64> 
+key:value;extra;...\n // zero or more line separated, fields cannot contain a semicolon, end with newline instead of semicolon, key lowercase alphanumeric, first alpha, only key is mandatory, only reserved is `content`
+content: // literally this word on one line
+<content>\n // any number of further line breaks, last line without break is signature
+<bip-340 schnorr signature encoded in URL-base64> 
 ```
+
+The canonical form is exactly this, except the last linebreak and the base64 encoded signature, hashed using SHA256. There is no need for placing the event ID in the wire format either, so this is also the wire format.
+
+The database stored form of this event should make use of an event ID hash to monotonic collision free serial table and an event table.
+
+Event ID hashes will be encoded in URL-base64 where used in tags or mentioned in content with the prefix `event:`. Public keys must be prefixed with `pubkey:` Tag keys should be intelligible words and a specification for their structure should be befined by users of them and shared with other REALY devs.