XSF Discussion - 2019-08-27

<ralphm> And indeed, maybe mod_block_strangers isn't the best approach. I can imagine various cases where you'd receive a message stanzas from a non-contact that you didn't direct presence to (bare or full). And didn't want it blocked.

For example, jmp.chat

Where you want messages from SMS non-contacts

They have to constantly change their server and client recommendations because of this

h

moparisthebest, maybe talk to the server implementations about white-listing jmp.chat

that’s a reasonable use-case

and since you need to be registered with jmp.chat to receive messages from them (?) it is opt-in for each user fully and without extra config

could be a config switch obviously for the admin to disable the whitelisting

but I think by default it should be whitelisted

What about > Also blocking messages from strangers, server-wide, is a very bad idea.

true

Guus Ralphm maybe we should apply for this: https://www.forumstandaardisatie.nl/content/toetsen-van-standaarden

winfried: i quickly scanned: seems we're to late?

Guus: They have a continuous call and they accept twice a year. We missed the call for this autumn but can apply for the spring

And best prepare well for it...

kk

Ge0rG + all: mailing list archives should be working again now

MattJ: awesome, thanks!

Are the numbers still the same?

You mean did old URLs break? No, I sincerely hope not

MattJ, https://mail.jabber.org/pipermail/members/2019-May/008986.html

oh, that’s members

but members should be public, no?

(it was, at least)

(I just grepped my xsf@ logs for a random mail.jabber.org link)

(other links to standards@ seem to work)

Yes, should be public

In principle, mailman knows which lists should be

jonas’: the evil thing about mailman silently renumbering is that all links still work, they just point to different mails

Yes that's horrible

At least for standards@ links archived by Google seem to match, with a quick sample

ralphm: thanks for checking.

I'm sure there are still broken links on the wiki, from our last silent renumbering.

When was that? I have old links in my blog and haven't noticed issues

2003-2005

ralphm: I suppose around 2016, when the infra went belly up

Ok

ralphm: eg. https://wiki.xmpp.org/web/XEP-Remarks/XEP-0352:_Client_State_Indication leads into a 404

https://wiki.xmpp.org/web/XEP-Remarks/XEP-0256:_Last_Activity_in_Presence has one 404 and one unrelated "XMPP or NodeJS" thread

those two were the first hits of https://wiki.xmpp.org/web/index.php?search=mail.jabber.org&title=Special%3ASearch&go=Go

Hmm

I don't even dare going on

Are you fixing them as you go?

Bear once provided me with server logs, that I grepped for frequent 404's

by no means a full fix, but I used it to fix the most high-impact ones.

maybe that can be repeated?

Particularly in this case, there's context to find the new working URLs

ralphm: nope. I have no idea where the links used to point to before

and the 404s are kind of unexpected

there used to be more wrong and less 404 links, IIRC

Well, you have links with known months. Give the relatively low volume, you can choose suitable replacements.

(just go up one level, scan for the XEP by number or name)

E.g. the CSI one: https://mail.jabber.org/pipermail/standards/2014-August/029037.html

Right.

jonas’, oh, right

I think that's part of my earlier attempts at a fix

Apache was serving archives/private, and all the docs say to serve archive/public

ralphm, Ge0rG, jonas’ : it's not just servers that block non-contacts either, also clients https://github.com/ChatSecure/ChatSecure-iOS/issues/844 pretty crappy situation

and yea jmp.chat getting itself on a whitelist is probably doable, but kind of ruins the whole concept of an open federated system :/

ditch whatsapp/telegram/$hotness_of_the_day and join XMPP and message anyone! (who doesn't happen to use a crippled client or server that they can't fix)

Well, for what it is worth, once I disabled that module, I almost immediately got a bunch of spam. I understand it blocks certain users, but I am not affected by that, and that trumps not getting spam. YMMV

and to be clear I think that's perfectly acceptable opt-in behavior, or even if it was on by default and you could opt-out

just to have it hard-coded in clients, and server-wide in popular public servers where you can't disable it for your JID is bad bad

Sure

Agreed - a standard way to enable/disable it would be great

Magic blocking command-ish thing?

Someone XEP it and we could implement it in Prosody in less than an hour

Or, maybe, you know, a way to smartly block just the spam messages.

Or, slightly less useful, a kind of captcha-on-first-contact

Yeah, I don't believe in that.

I'm tempted to say: my server will only ever forward anything (including presence subscription requests) to the client, if there is a matching outgoing presence request or approval.

And then something to cover MUC/MIX.

... invitations.

for MUC?

Yeah.

That's one of those things that typically fail with mod_block_strangers.

I don't remember how MUC invitations work, but in MIX there is the inviter - channel - invitee triangle and in that case it would indeed only work if both people have eachother in their roster

I'm not sure if that's a negative, depending on how hard you want to block spam

ralphm, MUC has both ways

with the MUC channel in between or without

The big issue, of course, is needing some kind of out-of-band exchange of JIDs, or maybe phone number matching.

with is required for rooms where members are not allowed to edit the member list, but are allowed to send invites.

When we were implementing (only) MIX, I looked in detail at its mediated invites, and really like that model.

mediated invites are not spoofable, which is nice, but the problem is with spam of those, yes

Because it won't cause blockage of invites from 'unknown' entities like the room (the invite comes directly from the inviter to the invitee), so that blocking JIDs will also never cause you to be bothered by people via MIX channels.

And then if you require a bidirectional relationship, that would block probably most spam.

(at the expense of ease-of-use, probably)

s/, probably//

ralphm, what you describe does not sound like a mediated invite to me

well, I suppose it is mediated in reverse. It requires the participation of the channel.

I.e. someone can join the channel only if it got an invite that was approved by the channel, and it will only receive invites from non-blocked people.

I don’t get this, do you have a link to the document for me to read?

jonas’: https://xmpp.org/extensions/xep-0407.html#usecase-user-invite

ralphm, ah, yes, that’s neat

so there’s a token from the MIX involved ✏

but I could still spoof that

ah, but that doesn’t matter because you’d be filtering non-roster contacts

If you wanted you could implement a step where the invitee checks the invite with the channel, before showing the invite to the user.

With three parties involved, you can't trust any one to represent the other.

I've never blocked messages from strangers, and strangely I hardly receive any spam

Ge0rG: maybe you are a natural anti-spam measure 🤣

It used to be different.

ralphm, that requires a way for the channel to say "yes, that token is valid" without joining

Indeed

ralphm, this is simply one of the occasions where Ge0rG did (does) what he was (is) preaching

jonas’: if you are going to join anyway, and that join depends on the token being valid, you can just skip the round trip

Clients are auto joining for years now.

Ge0rG, the point is to validate the token to rule out dumb invite spam

The point is that you may want to validate the invite before bothering the user

unless you’re collaborating with the MIX service, you don’t have valid tokens to invite people

In this scenario, you'd minimize spam.

Also, implicitly the inviter does trust the channel

Spammers would never collaborate with a MIX service

So that's why I think it works

if the spammers collaborate with the MIX service, the obvious solution is to punish the MIX service.

> ralphm: there is a disapproved SPAM WG for that, in which you can become a member after signing an NDA with the blood of your first-born. That offer is still open, BTW, in case you are interested in not blocking strangers.

How much is invite spam a thing? I've never experienced it (I mean from spammers. I do get invite spam otherwise but from "legit" users)

pep.: never got that so far

It's been a long time since I got a bonfide invite

Most invites I'm getting from myself as a shortcut to join a MUC on my mobile

But I get multiple invites per week

ralphm: do you happen to have xml?

Not at the moment, but can hold on to it

Next time

ralphm: that would be great.

Got a few from default.rs

any updates regarding DOAP ? gajim does also provide one now

There's a PR awaiting, not sure what's blocking. I'd say editor's processing time

I'll have a look after we get together with jonas’

Wiring a DOAP looks like a significant effort

copy an existing, edit the name, call it a day

Just implement all the features, then you don't have to filter XEPs ;)

wurstsalat: fewer features, less work.

I see your point

Ge0rG: I'm sure somebody(tm) could PR a doap file for yaxim once it's deployed

Then you'd only have to update it

pep.: I'd actually appreciate that

Ge0rG, do you have a list of supported XEPs?

wurstsalat: more or less, at https://yaxim.org/features/

pep., the website is not editors realm

Ah

Board?

I just happen to know a bit about pelican so I did a few things back then

I don’t think there’s a formal team

actually

I have merge powers there, not sure why :)

Guus and I do most of the reviews

Then we should submit that PR to board probably

Ge0rG, Feb 1st, 2017 4:06 pm is sufficiently recent?

wurstsalat: probably not, but it's the most recent I have ready.

If nobody else volunteers I would compile a doap with this

Didn't someone make a ???? to doap thingymajigger?

Ge0rG, there you go, an approximation ;) https://paste.gajim.org/view/22c58cfb

wurstsalat, 0077 "complete" "no forms support", hmm.

That was me not parsing ;)

Is that rdf file now licensed under gpl3?

Should I also add the version tags for the specific XEPs?

yeah that'd be nice, maybe not required though(?)

disco#info to doap? or was this the project that needed the registries to be in order?

disco#info to doap could help a bit I guess.

wurstsalat: Is that rdf file now licensed under gpl3?

hm the tombstone thing where we redirect to another address on destruction of a muc

if i disco such a muc, it has the new address inside <gone>new adress</gone> error condition

is this somwhere specified ? or is this something people just do

XMPP core RFC

https://xmpp.org/rfcs/rfc6120.html#rfc.section.8.3.3.5

I would’ve pasted that if I hadn’t accidentally Ctrl+Q

Ge0rG: however you like

WTFPL?

Tell me if I have to be specific ;)

ok nice although weird that they add xmpp: into it

lovetox, it makes sense to be a valid URI I think

lovetox, handy if you ever wanna redirect to a wobsite or email or whatever I suppose

lovetox: I thought gajim did that (but didn't check)

wurstsalat: I'm not yet sure whether to bundle it with the source or with the website.

Zash: I don't want to design the UX for that

Yes, convention for where to put the doap xml plz 🙂

Zash, wherever you want? You have to give a url to xmpp.org anyway

Ge0rG: "This MUC has now become an mailing list. GL;HF"

Channel you are in is tombstoned, suddenly a "new email" editor appears

Somewhere not everybody has access would be better I guess :)

Ge0rG, show a link maybe?

wurstsalat, "public domain"?

Zash still weird, this makes parsing this much more complicated

lovetox, don’t you need a URI parser anyways?

Life is complicated.

i have one yes

And it's most likely always going to be another MUC.. (or MIX, maybe? someday)

Just drop it at the OS URI handler. If you are lucky, the xmpp URI will get bounced to your running instance.

Or maybe an http url to logs? :P

Note that it's a generic stanza error, applicable to anything and everything.

If you agree less lucky, you'll end up with a second client running, competing for your resource

Users, MUCs, pubsub nodes, entire servers etc

Everything can be gone.

Messages?

"The recipient or server can no longer be contacted at this address"

https://http.cat/410

Hm, maybe that excludes pubsub nodes then

Makes me think of the Moved XEP mess...

Are pubsub nodes recipients?

Moving is a mess

Cool URL^W JIDs don't change!

I moved to the web. Feel free to subscribe to my blog rss

Now imagine we had an URI scheme for individual messages.

Linking to a static website where you detail your shutdown seems like a thing you could do

Imagine if we had URIs in to/from for everything

You could link to your last message, like a will

Zash: heresy!

`<message to="mailto:jdoe@example.com" from="xmpp:me@example.net" type="normal"><subject>Buy!</subject><body>Lorem ipsum</body></message>`

Sure would have simplifed some bridging scenarios

Ge0rG: poezio, dino, and gajim host the doap in their git repos (easiest I think)

pep: the doap from poezio follows a different scheme though (I think Link Mauve updated it)

wurstsalat: so I'd link to a raw file on github? Hmmm...

blame Link Mauve

(he knows better)

Ge0rG, yeah

So be it, then!

wurstsalat, I think I updated all DOAP files I knew about when I improved the schema to have more consistent semantics.

I’ll have a look at some point, currently in Berlin and enjoying it too much to be too much on the computer. :D

debacle btw, I’m in Berlin atm.

linkmauve: did you tell Holger?