jdev - 2021-03-11

Found out that disroot.org operates an open irc/xmpp bridge and was briefly excited, but now I am quieted or banned from at least one room (presumably for repeated join/parts) and I still can't figure out how the hell to authenticate with nickserv *facepalm* I hate bridges.

Except, weirdly, I can use the matrix.org xmpp/matrix bridge, and then join an IRC room through their matrix/irc bridge, and somehow that works better than just going directly and how to use nickserve is actually documented :S

Sam, what kind of bridge is disroot.org?

I'm not sure

because biboumi is fairly well documented: https://doc.biboumi.louiz.org/9.0/user.html

Oh, it is Biboumi, just went to the page to see if it said.

I looked through those docs, didn't see anything about nickserv.

check for "Authenticating"

also, a text search for NickServ would’ve brought you there ;)

Oh yah, this is what I was trying to do, but it wasn't working.

it does work for me on the one network where I set it up

I was probably searching for "NickServe" or something stupid, because I definitely did that

It just keeps telling me that the commands are wrong or something. i dunno, it only messages me half the time and I keep having ot disconnect/reconnect to make it even send them, and gajim won't actually let me do adhoc commands without jumping through hoops (there's an open bug I found for it). Everything about this is terrible.

Curious, I have the opposite experience. I got complaints after joining a Matrix room via bridge*, but nobody on freenode even notices that I'm connected via Biboumi, so it doesn't generate any of the free marketing that the Matrix-IRC netsplits do. ✏

Not to mention that I had to install gajim because nothing supports adhoc commands but for some reason things insist on using them instead of just letting me send them commands as a message. *grumble, grumble*

(poezio works, too) ✏

Can't you send messages to nickserv%ircnet@bridge ?

Sam, well, sending commands as text (a) conflicts with TUI clients and (b) is terrible when used with automated things

I think an ubuntu manpage showed a nickserv command example using some syntax I'm not familiar with (probably some raw IRC thing). ANyways, no idea, it's been a pain.

jonas’: and yet, the drawbacks are minimal and it works everywhere.

I’ve had one bot do … suboptimal things … because you could make it say /foo and the bridge was stupid and based on libpurple and interpreted that.

Sam, that is your opinion. But you’re also the author of '393, sooooo… ;)

I mean, don't get me wrong, I get the pain points, I accidentally send people :quit or something all the time, but literally nothign but gajim supports adhoc commands.

393, which is widely adopted and works fine, yes.

poezio supports them

Great, 2 clients out of dozens support them. That's not better.

ok, you want to rant, I’ll leave you at that

I was just hoping someone would know how to authenticate this, since those docs still don't give me any useful information.

I thought SASL worked, pretty sure that's what I was using with IRSSI, but it didn't do anything. Maybe I should try it again, I might have forgotten to reconnect or something.

Try in xmpp:biboumi@muc.poez.io?join

Will do if trying sasl again doesn't work, thanks

*sigh* now it just says "Error connecting to server". No idea what that means. Maybe Freenode banned me for too many reconnects or something.

Or "ERROR: Connection closed" or something. Anyways, everything is broken. Will try the biboumi room later.

But yes, slight rant starting about every damn thing we ever do in XMPP land: how am I supposed to use this if I don't know anything about XMPP? For a very basic use case, the disroot site says "use this format and you'll join an IRC room". Great. But as soon as anything goes wrong, there's no way to know how to get help even. If I send a message to anything, they dont' respond, my client probably doesn't make it clear that commands are a thing even if it does support them at all, etc.

I blame disroot for not linking any reasonable documentation and your client for being incapable of either implementing adhoc or supporting biboumi specifically.

fwiw, for my client project I envisioned having built-in support for talking to biboumi

I don't generally like the idea of super specific integrations, but TBF that would make it a lot easier for users. disroot could link to better documentation, that's fair, but I feel like if my server supports it I should have some way to get to those docs or get help from my client without going and looking for it.

Like something as simple as biboumi or whatever responding with a help message and not just ignoring me if I message the gateway would be nice. Even if it's just 'this is just a bot, here are the docs:'

on the opposite side, a friend wanted a better way to join IRC from mobile, so I had him install Conversations, sent him a link, he clicked it, and he's been happy ever since

Sam, go ahead and make a MR for biboumi, I think that’s a good idea even.

What's an MR?

non-githubese for PR

ahh, gotcha

because biboumi is on a gitlab instance

Is it? First search result is github

Either way, I don't write Python or C++

ugh

obligatory "but it's not C++ it's MODERN C++" :P

Don't care, hate them both for different reasons :)

It wont' even let me view the issue tracker without an account though, or I'd try to file an issue at least

no I'm with you, except I also won't write Go :P

All languages are terrible, except Lua. Lua is love.

That's sort of fair. Go is the least-bad garbage in my experience. Lua is terrible, it constantly defines variables when you slightly misspell something and then breaks in impossible to debug ways *grumpy*

it's nice everyone can have a favorite language or two

🎉 SASL worked apparently. Still no idea what was wrong before, but after randomly failing 3 or 4 times with a useless error message it finally connected.

Okay, it's working, now careful not to touch it forever.

Sam, really, for arbitrary interactions with an entity there’s not much better than adhoc commands… Sure you can have some kind of text-only fallback through messages if you want to quickly debug stuff, but the UX is sub-par and it is very error-prone

Oh, they're fine if the client supports them, but none of them do so it seems like there should be an alternate one.

well, 0100 is very limited in its scope sadly

Even if the client does support them, I don't see how you'd discover that they're the way to configure this gateway

(but any kind of textual communication with a gateway has to be ad-hoc which, ew)

But maybe that will just happen if they were more widely supported and it wouldn't be a problem.

Okay, re-enabled all the IRC bookmarks I created. Restarting client, let's see if I actually join to all these rooms or just get bombarded with errors again…

test?

huh, now Conversations shows me as offline and unconnected to this room and won't fetch history. But sending a message worked. I give up.

Sam, fwiw I'm also on team "ad-hoc commands are annoying"

I hate that I have to get out poezio every time I want to configure biboumi

I mean, don't get me wrong, they'd be nice if things supported them, but I don't think they're generally all that useful (a gateway is pretty niche) so most things probably will never support them. Maybe if they had some more general purpose use, I dunno.

"client developrs who refuse to implement ad-hoc commands and forms are annoying"

but yes, having to fire up another client to configure things is never ideal, obviously

I don't think that's the case though. Why would client devs implement them for the most part?

by far my #1 complaint about all gateways though is how they tie things to presence

eta, biboumi doesn’t, afaik?

IMHO a gateway should *never* kick you out of a MUC

(unless you've actually been kicked from the legacy network side)

Like the Matrix-XMPP one?

because getting clients to stay in MUCs is hard enough as is without the gateways screwing around

whatsxmpp takes the attitude that MUC join state should be persisted to the DB and restored on restart

eta, to be fair it should be mapped to whatever the remote network behavior is supposed to be

leaving a whatsapp/signal/whatever room because the xmpp side left is truly awful

no don't do that (but nothing does apart from maybe spectrum)

I wonder if it's worth putting adhoc commands in the compliance suites? Would that be enough for client devs? Or maybe we need more uses for them first to justify that. I dunno, just thinking out loud.

what I'm complaining about is when your IRC connection drops under biboumi and you get kicked from all of your MUCs

or when a gateway is manually rebooted and the same thing happens

Actually, no, I think I'd be against that. Still undecided, but this is super niche. Seems like it would just be a burden on client devs. Maybe gateways and things just need to implement a fallback.

eta, ah.

gateways should remember the user's intent (if they joined a room and never left it, they probably want to stay in it!)

(+1)

requiring the user to "babysit" the gateway is incredibly bad UX

like it annoys me and I actually know things about XMPP

for someone who isn't an XMPP fan they'd just consider it an incredibly broken experience

Sam, adding adhoc to compliance suites seems hard to do

also sending unavailable-presence to the gateway shouldn't log you out of the remote network either

(biboumi doesn't do this, thankfully)

Yah, that doesn't seem like a good way to encourage implementations anyways. I dunno, I keep going back and forth on that.

Making them more useful first is probably the better way.

maybe we need a new category for those? :D

I think for clients with ad-hoc commands, they're lovely

like honestly, great way to configure things that isn't like "wtf how do I use this text interface"

but it's really ungrateful work for the dev

but right now they're not supported enough to be the only method of config

Sam, there are nice XEPs with standardized sets of ad-hoc commands, which means clients don’t have to have the full adaptability of 0050 + 0004 to use them, which is great

but that cannot really work for gatewyays

How many things need configuring though? MUCs do their own thing IIRC, so it's just gateways and maybe server admin stuff, right?

btw while we're on the subject the gateway registration XEP is kinda trash IMO

eta, yes.

much better to just use adhoc / textual commands

Maybe it would be worth it to start a thread on standards@ about gateway interaction

I’ll try to collect some feedback, there is one guy who is writing some spectrum-like generic gateway software block using slixmpp lately and he has implemented XEP-0100, I will ask him for some feedback on top of my own, if he has time

Good idea

I'm slightly confused about OTR.

https://otr.im/ is this related to XEP-0364 ?

It's a newer version of https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html right?

But is this used in any XEP or is anyone aware of that project?

all xmpp clients probably implement OTRv3

as v4 is relatively new

Sofia Celi of https://github.com/otrv4/otrv4 once reached out to the XMPP community, but I never heard that someone tried to XEPify OTRv4

Okay good to know

it seems https://github.com/coyim/coyim is using it