update terminology and todo

2 files changed, 44 insertions, 27 deletions

diff --git a/terminology.txt b/terminology.txt
index e4157b2..a0c7e16 100644
--- a/terminology.txt
+++ b/terminology.txt
@@ -3,15 +3,24 @@ so i'm kind of figuring this out for myself
 
 anyway
 
-pylon: a chat server that wilson makes a connection to
+Pylon: an outgoing connection from wilson to some chat server/service
 	which could be "some irc server", "some xmpp server"
 	or "discord" (discord is centralized so there's only 1 discord to connect to)
+			(though you COULD have multiple Pylons for discord, if you were crazy)
 		note that discord's concept of "server" aka "guild" is unrelated to anything
 
-channel: a particular chatroom on a particular service
-	eg "#a on apionet" or "#general in some discord guild"
-	in the code, a channel is identified by a combination of a pylon, 
-		and a string 'channel descriptor', whose format depends on the pylon type
+Channel: a particular chatroom on a particular service
+	eg "#a on apionet irc" or "#general in some discord guild"
+	in the code, a Channel is identified by a combination of a Pylon
+		and a string 'channel descriptor', whose format depends on the Pylon type
 	for instance xmpp channel descriptors are jids, discord uses numeric ids
 	
-bus: a family of connected channels that messages will be bridged between
+Bus: a family of connected channels that messages will be bridged between
+
+Message: you know what a message is. it has a bunch of fields, which are
+	source_channel: the Channel the message came from
+		maybe rename to source
+	body: the string contents of the message
+	sender: the username (on the source service) of the message's author
+		TODO we need more info than that surely
+
diff --git a/todo.txt b/todo.txt
index fded18e..647f7ed 100644
--- a/todo.txt
+++ b/todo.txt
@@ -1,27 +1,35 @@
+structure:
+	decide on a proper structure for Message objects, and write it down
 
-discord and quaddle hard-depend on the configured url ending with a /
-note that http does not conflate // into / in the path.
+general bridging:
+	pfps
+		xmpp: serve pfps from file, on request
+		xmpp: obtain pfps and turn them into a public url
+		discord: obtain pfps into a file
+	edits and deletions
+		Message should have a type field, everything needs to support that
+	messages without a body but just attachments
 
-at least for nanochat, multiple coros interact with the socket.  a little work has been done to lower the chances of one yielding and then another trying to do things and reading stuff meant for the other one, but it's a race condition.  there is no way to do a write() then read() without a potential race condition, or magically knowing how much to read exactly.  so, the socket should be directly controlled by a single thread of execution, then the recv and send coros should interact with that via *>An Interface<* (robotic voice) (i.e. wrap the protocol away into a protocoller and the pylon only deals with the messages and not lower details)
+config:
+	some ui for changing bridge settings/adding new buses at runtime
+	? should this rewrite the config file or something?
 
+logging:
+	subloggers, somehow
+	pass this into r.web and so on, somehow
+	
+puppeteering:
+	detect existing nicks in use, avoid collisions, keep this in sync
+
+store:
+	nicer web ui
+	fts 
+	sort by channel, etc
+
+
+irc:
+	port to unrealircd s2s protocol
+	OR switch to multiple c2s connections
 
 
-2026-09-15 13:47:16+0100 error [xmpp-olive] ./xmpp/pylon.lua:98: attempt to call a string value (local 'x')
-2026-09-15 13:47:16+0100 error [(toplevel)] 👉xmpp-olive ./xmpp/pylon.lua:98: attempt to call a string value (local 'x')
-stack traceback:
-	./xmpp/pylon.lua:98: in function 'xmpp.pylon.recving'
-lua5.4: 👉(toplevel) 👉xmpp-olive ./xmpp/pylon.lua:98: attempt to call a string value (local 'x')
-stack traceback:
-	./xmpp/pylon.lua:98: in function 'xmpp.pylon.recving'
-stack traceback:
-	[C]: in function 'error'
-	./log.lua:42: in function 'log.loop'
-	./pylon.lua:30: in function 'pylon.run'
-stack traceback:
-	[C]: in function 'error'
-	./log.lua:42: in function 'log.loop'
-	main.lua:71: in method 'run'
-	main.lua:78: in main chunk
-	[C]: in ?
 
-yielding() iterator inside of cqueues where the iterator uses cqueues read inside of itself mayyy be causing issues??  rebecca says no it's using the proper cqueues coro wrapper.