Use shortname config rather than hard-coding [x] and so on.

Pylons may also make their own choce in how they format the short-name
when sending out (or do it differently altogether), rather than it being
baked-in by the receiving pylon.

1 files changed, 24 insertions, 4 deletions

diff --git a/todo.txt b/todo.txt
index d79aa3c..fded18e 100644
--- a/todo.txt
+++ b/todo.txt
@@ -1,7 +1,27 @@
 
-pylon.subclass should not have a pylon_type arg. is only used for logging. a pylon's _name_ should be used in log messages.
-
-pylons harcode prepend names with [x] [d] [n] etc. this is not robust and is weird it should be in some way dynamic? maybe pylons can have configured short names? but then what in the case of two channels with different users of the same nick? they should not be conflated..
-
 discord and quaddle hard-depend on the configured url ending with a /
 note that http does not conflate // into / in the path.
+
+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)
+
+
+
+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.