Repository navigation
Conversation
ZNC and soju each left a gap Seance did not cover. Each fix goes by what the server offers, not by which bouncer it is. - ZNC's buffer replay (`BATCH +x znc.in/playback <target>`, on every attach) was unwrapped and handled as live lines. It now goes the catch-up's way: appended, counted as unread but silent. ZNC has no msgids, so a line not newer than the conversation's newest message is dropped, and a buffer ZNC keeps is not shown twice. - Behind a bouncer (BOUNCER_NETID, soju.im/bouncer-networks, or a znc.in/* cap) the autojoin waits for the bouncer's own JOINs. If it gave any back it owns the list: a saved channel it did not give back was left from another client and is not JOINed again. A bouncer that gave none back gets the saved channels, as before. - soju offers web push only as soju.im/webpush: the same command, VAPID token and payload as draft/webpush. Seance now asks for it too. - Search: soju refuses a search over every channel without in= (`FAIL SEARCH INVALID_PARAMS in`). Seance then asks each joined channel (up to 30) and answers once, for the rest of the connection too. soju takes only timestamp references, so the window around a hit is asked for by the hit's time. - soju.im/bouncer-networks: a login without a network is soju's control connection, which has no channels. It no longer JOINs there; it lists the networks and adds each new one as a network of its own, the same server and login bound with `BOUNCER BIND <id>` before CAP END. A network the user removes is not added back. With -notify, a network added on the bouncer later is added the same way. Tests: test/irc/bouncer.ts (new), and the soju cases in historysearch, webpush and caps. Docs: irc-layer.md § Bouncers, client-features.md § Searching history.
- ZNC playback: know a buffered line by its time, sender, target and text, counted per conversation, instead of dropping everything not newer than the newest message. Lines seen live are skipped, two equal lines in one second both stay. - Behind a bouncer the saved channels are never JOINed: the bouncer's own JOINs are the list. - soju search without in=: ask the channels one after another (0.7 has no labeled-response), uncharged behind a bouncer, no cap, and a part that fails fails the search. - soju networks: add only after a SASL login (soju binds no PASS login), only from a connection that is not itself bound, at most 20 per list, ids checked before they are stored or sent, entries added by hand as account/name count as saved; with -notify the list is not asked for again. - The service worker binds a soju network's own connection too, so a reply from a notification reaches that network.
The cap of 20 counted one list at a time, and each -notify line is a list of one, so a bouncer announcing new ids one by one got all of them added. Count what the entry offered before (bouncerSeen) against it, which also bounds bouncerSeen.
This branch was previously deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Bouncer compatibility for ZNC and soju. Every change keys on what the server offers, so nefarious2 and plain ircds see no change.
BATCH znc.in/playback) is delivered as catch-up: appended, counted unread, no notification or highlight. ZNC has no msgids, so a buffered line is known by its time, sender, target and text, counted per conversation; a buffer ZNC keeps across attaches is not shown twice.znc.in/*caps) or soju (BOUNCER_NETID,soju.im/bouncer-networks) the saved channels are never JOINed; the bouncer's own JOINs rebuild the list, so a channel parted from another client stays parted. Same rule as gamja.soju.im/webpushis requested alongsidedraft/webpush. Same command,VAPIDtoken and payload.FAIL SEARCH INVALID_PARAMS inis asked once per joined channel, one after another (soju 0.7 has no labeled-response), and the parts are merged into one page. A server withMSGREFTYPES=timestampis asked for a hit's context by its time.soju.im/bouncer-networks): a login without a network is the control connection. After a SASL login, each network it lists is added as its own saved network, bound withBOUNCER BINDbeforeCAP END. A network the user removes is not added back. Ids are validated, at most 20 per list. The service worker binds too, so replying from a notification reaches the right network.Testing
test/irc/bouncer.ts, plushistorysearch.ts,webpush.tsandcaps.tsupdates. Full suite, lint, typecheck, build and the smoke scenario pass.Notes
serverPassword. Whichever lands second takes that.*playbackmodule, CertFP.