jesopo

uncertain; pending a discussion on potentially quantifying how much non-utf8 data we deal with. the only feasible outcome i can see is dropping nonutf8 at ingress, and that depends on...

Huge +1 for this spec - seamlessly being able to push people off a leaf so it can be rebooted is a very cool idea. That said, I really think...

Copied from [`delivered`](https://github.com/ircv3/ircv3-specifications/pull/346#issuecomment-463839968): > Added a nice small implementation of this in [jesopo/bitbot@6a67c37](https://github.com/jesopo/bitbot/commit/6a67c37d) that does both `+draft/delivered` & `+draft/read` in one `TAGMSG` on private `PRIVMSG` and `NOTICE`

Would it be worth making considerations for server validated/provided keys? e.g. client cert fingerprint? this might need something like what message-tags do (prefix key with `+` to denote client-provided) though.

for access control expression, how about we mark messages with named access types and then tell each client what named access types they qualify for? very very rough example to...

I think we can move forward on this spec without defining how to tell clients who/what is allowed to edit what. for the time being, servers can just reject attempts...

> Regarding message validation, it seems this is settling on server-side which makes me fear servers may end up disabling it due to the high cost, plus the inability to...

I'd like to spec out edit/delete reason field. e.g. `this message was deleted: spam`

https://man.sr.ht/git.sr.ht/api.md#apiusernamereposname

not sure if this is actual practical but you *can* do a SASL dance at any point during a connection - doing it immediately when setting SASL config and then...