XSF Discussion - 2021-04-12

wgreenhouse: XMPP messages can cross multiple lines though

moparisthebest: I'm aware; should've said no more than one message per line :)

(the MAM output I grabbed isn't pretty printed or anything)

what format is it in?

ben: it's just all the xml stanzas from the MAM archive, in one xml file without a DTD, in between <message-archive xmlns="https://linkmauve.fr/protocol/pie-mam"> ... </message-archive>

without linebreaks, except where there happen to be linebreaks in a message body

you could probably rig something up with the tools in html-xml-utils like hxselect or hxprune

maybe even hxpipe

hmmmmmm

A proper way may be an xpath query sent to xmllint --pattern ?

But you could probably just sed out the XML...

ah yeah xmllint could probably do it too

would want to preserve the from, to, and stamp tags, but the rest can be discarded

sed can match and replace :)

I thought parsing xml in re brought about the coming of zalgo ;)

but thanks both, this gives me some to chew on

yeah it might, but if your schema is regular/small you will probably be fine

Sorry your requirements didn't say "I want this to work without summoning demons"

;)

that said, what hxpipe makes for this file looks friendly to re search/replace

nice

Does XEP-0077 support registration with an empty password?

I guess you could just do <password/>, no?

Yes #3.1 says "the <password/> element MAY be empty". But later:

> If the requesting entity does not provide all of the requested information during registration [7] then the server or service MUST return a <not-acceptable/> error to the requesting entity.

Footnote [7] says:

> This includes providing an empty password element or a password element that contains no XML character data, i.e., either <password/> or <password></password>.

Regarding password _change_, the XEP is clear:

ISTM that the footnote is worded poorly

> If the user provides an empty password element or a password element that contains no XML character data (i.e., either <password/> or <password></password>), the server or service MUST NOT change the password to a null value, but instead MUST maintain the existing password.

aaagh

confusing!

I give up

Huh. Both <password/> and <password></password> are the same thing.

And it says they’re to be treated the same, doesn’t it?

Sure, I don't think the XEP says otherwise?

Question is, how to treat them :-)

Is it like NULL, None, "" and False are the same thing?

They must be treated the _same_. But _how_?

when registering (not password change), i dont see how the client would need to care how the server treats an empty password

what i wonder is, can i do auth with an empty password?

Empty string as password? Sure.

lovetox: My question was how the server is supposed to treat it though :-)

Holger, i would say if its not a valid password according to your policy decline it

otherwise go with it

or does that lead to a problem?

Well the question is whether empty passwords are supposed to be supported by the spec. If so it would obviously still be a policy decision of the admin, yes.

ok is this a theoretical question, or is there an actual use case behind that?

Well I'm touching this part of our 0077 code and was interested in whether I'm supposed to support the empty password case.

this remind me that I have to do my ejabberd upgrade 🤔

i would not, because probably many clients dont support that

!version movim.eu

If I had the answer to this question I could still decide whether or not to follow the spec. But seems the answer isn't obvious so I can just decide on my own :-)

or i would wait until someone comes and at least asks for that with a concrete use case, and how clients and server are expected to act

Holger, FWIW, I’d hide allowing empty passwords behind a huge red button labelled "world destruction"

lovetox: Yes yes I'll survive without clarification. I just had this weird idea that one of our core specs dealing with passwords could be clear on the topic of empty passwords :-)

:D

I think we'll just reject them, partly to remain consistent with the password change case where empty passwords are explicitly not supported.

Reminder: Office hours are tomorrow. This week is a round table discussion "Towards XMPP 2.0" https://wiki.xmpp.org/web/XMPP_Office_Hours

13th April, 16:00 UTC as always

I don’t know if it’ll work out, but I’ll try to make this one.

Sam, would it be acceptable to open a peertube channel that mirrors the videos available on youtube? (asking as I saw the new yt channel in the newsletter, we’re bound to have people asking why it’s only on youtube)

(I am not asking you to do it at all, but asking for permission if I find the time to set it up)

mathieui: we've gotten a lot of that already :) I'm not against it, we just need someone who knows how to set all that up to do it. I couldn't find a good instance that actually had open registration, and don't want to do more work myself for something that's not likely to be widely used, so automatic sync would be nice.

Go for it as far as I'm concerned :)

Ok, thanks!

Yes, usually it is not that we dont want it, but lag resources or have technical limitations (unless we invest more resources)

On the subject of XMPP 2.0, I wonder why Jabber/XMPP was never really adopted for open source projects setting up public chats? IRC had (*really*) early-mover advantage, but it can't all be that...

You need a server/account to host a MUC? MUC doesn't scale to more than a couple hundred participants? IRC was good enough?

#nolibs

irc is implemented in half an hour, while xmpp is, well...

That doesn't matter when you're a user, right? That is, I'm more wondering, would something like Freenode for XMPP be able to exist then? Now?

ah, i misinterpreted the question for embedded chats

There's still a definite need for this, considering that, ehm, IRC is still widely used, even with a lot of projects moving off to Discord/Gitter/Zulip/Mattermost/whatever. ✏

Freenode considered switching to XMPP at one point, I think. I don't know the details though, but maybe you could find their reasons

Hah, interesting, I use Freenode as an example though, mainly because it is (was?) the default choice when you wanted to set up a room for your project.

I spoke with some Freenode folk a year or two back. I got the impression that it was mostly just resources and need of a concrete plan

i don't recall having an IRC frontend for XMPP MUCs

they exist but thar be dragons https://github.com/moparisthebest/xmpp-ircd

Outch, owie, my nightmares

> You need a server/account to host a MUC? MUC doesn't scale to more than a couple hundred participants? IRC was good enough? maybe the fact that fewer xmpp clients support anonymous login, whereas (at least in the past) most big irc support channels don't need a registered account

Yeah, the ease-of-setup aspect here is crucial I think, even as an operator. Find a channel name that's not used, *boom* you're a moderator.

Well, installing and configuring an irc client for a given network, with servers limiting who may connect by geoip, is quite a challenge. I'm not sure how much easier it is than xmpp

geoip or open proxy bans today certainly make it harder to get started on irc. but 10-15 years ago I think it was simpler to get started without an "account"

path dependence is important too of course

deuill true, though nowadays it's pretty easy to create a MUC on [arbitrary server] maybe not even the same one where you have your own account

and it can be made persistent without the need of ChanServ, or someone with a good enough connection to sit on the channel

possibly in the past, when there were fewer public XMPP instances outside of proprietary installations, that was less true

Too much choice doesn't make it easier. Like, if you're a free software project then you'd probably go for something on Freenode, but in the XMPP world, where would you go?

good question. esp since current trends advise people to scatter

(e.g. formerly big public instances like jabber.ccc.de saying "go somewhere else")

Also having an easy to deploy web chat is a good thing

I've heard that yax.im is breaking apart under the load...

Ge0rG: wait, is that a joke that I don't get or are you having load problems? I'm curious because I've been pointing people there when they ask

Sam: https://yaxim.org/blog/2021/04/09/vaxbot-performance-challenge/

Sam, you are from now on named "sole source of yax.im performance problems"

oh cool, thanks for the link. Reading.

Well, at least I have some prosody performance numbers now.

Some SQLite performance numbers :)

the best ones

MattJ: well, do you have comparison numbers of different MAM backends from production?

No, we've not run such tests on a production server

So how am I supposed to decide, what to replace sqlite with?

Just saying, I think the conclusion was that you reached the limits of SQLite on your hardware, right? (unless we give up some consistency guarantees)

Yes, and it looks like psql will give me roughly 3x the performance, but that's from synthetic benchmarks

We have performance tests, I guess you can try running them on your server (it doesn't actually have to be the running Prosody instance)

I'd love to