XSF Discussion - 2020-05-29

pep., I don’t recall text in MIX which says otherwise ✏

but it’s been quite a while since I’ve read MIX

in some discussion a few days back, I was looking for this, and now I found it: https://multiformats.io/multihash/

don’t ask me what the context is though

might be about the blake2 stuff

jonas’: you forgot to add a blockchain trigger warning to the link ;)

larma, I didn’t notice anything blockchainy in there

multiformats is from protocol labs which is blockhcainy 😉

TIL (and don’t care)

They invented ASN.1 ?

Zash, how is this related to ASN.1?

OIDs

they’re not OIDs though?

The concept of { oid, hash bitstring } ?

I don’t see OIDs there though

OIDs are hierarchical

yeah, they're not using OIDs, they are just prefixing the hash with a type and it's length

I don't mean OIDs specifically

Maybe I've just looked too closely at the whole ASN.1 thing, so to me it looks similar.

It's the same but worse

Zash, you mean they could have used ASN.1 instead?

They could

but they are blockchainy

why would you though

so they mind every byte

ASN is odd with it’s different serialisation formats

Says the developer working with XML :)

yeah

ASN.1 has an XML serialisation format 😉

Is memberbot online, and should they be?

We're in voting, so they should be.

That was my thought.

it’s available for me

Hmm. I wonder if S2S between my server and xmpp.org is down.

Ah. Has xmpp.org enabled the 'I won't talk to small DH Keys' Prosody thing?

gender-neutral singular "they" replacing "it" for things? :P

bots are people too!

I'm sorry

Kev, yes (but to be clear it's not a Prosody thing, it's system OpenSSL defaults on Debian 10)

Pretty sure it's been configured to prefer ECDHE

Ah. Any chance that could be turned off, as an easier option that updating my server to a release from the last millenium? :)

And actually probably most distributions now, at it's recommended by openssl since.. yet another vulnerability not so long ago ✏

jonas’, flow, is the 157 validation thing gonna delay/make the PR get refused? :/

Can we change that later if it's the case?

I kinda rather you added text that says everything should be URIs

I don't mind the way we do it, I just wanted it in :x ✏

But as flow said, adding this kind of text on all fields now might be considered breaking (even though I would expect people to just put URIs in there already as the example suggests)

It's not Standards Track

so.. that means we can bend it in any way we want it's fine? :p

We can bend anything we want any way we want.

We have the power!

We are the last XEP benders

pep., it already delayed the PR. I personally see no reason why this should cause the PR to get vetoed by council, but since it takes only one council member to veto…. In any case you could resubmit without, which would be sad. But we can not add the data form validation later on, without bumping the namespace, so it was important to do it now.

I found out today that most of the spam that I get through XMPP is coming from my secondary account, on jabber.org, instead of my primary account on igniterealtime.org. What strikes me is that I publish contact details including the latter a lot more than the former.

I too get a bunch of spam to my jabber.org account, despite never having written about it anywhere or barely used it for more than occational testing.

We're working on it!

> We're working on it! Is Neustradamus around?

;-)

Having something anti spam on jabber.org would obviously be nice, but I wasn't so much calling for action as I was expressing surprise at the source of the spam I get. It would be interesting to find reasons why an infrequently used account gathers more spam than an actively used and shared one.

I do now wonder if the recent uptake in spam and the recent instability at jabber.org are related.

Guus: I imagine you'd find a ton of legitimate accounts by taking a random list of email addreses and picking out the localparts.

That wouldn't get you my jabber.org account.

Maybe the reason it seems to be more is that you look at it less often, so the spam waves get buffered up in offline storage

I'm logged in all the time, but am not using it for anything other than ... what, really? As a fallback in case my primary account has issues, mostly.

Weird

I receive lots of spam on my personal account on my personal server, but it appears to be fluctuating quite drastically from day to day.

Guess I made it to some spam list...

same, it went away almost entirely for almost a year I'd guess, but now it's back up to a few a day

But in my case, an account with no contacts that I never use and never mentioned anywhere, still getting spam? They must have guessed.

Can we assume that it's mostly one entity that's driving all of this spam?

Zash: maybe some kind of way to list accounts on a server or something?

Xep 55 with a wildcard?

Does jabber.org have that enabled? That'd be scary.

No. It supports xep55, but it's opt-in.

or.. the db got leaked! :p

Or any db got leaked, and they tried every username on every server

Kev, opt-in by the client?

pep.: Yes.

So like MAM? :P

Well, by the user through their client.

opt-in but every client uses it ✏

I don't follow.

It's a joke. I don't know if it's the case for 0055.

MAM was made opt-in on most servers though

For GDPR reasons among others

But every client uses it anyway

Opt-in by using it!

But for 55 I'd hope it be a thing where you register with it to opt in

You don't register with it, you tick the box in your user configuration adhoc.

But that's probably equivalent.

Right

You mean your client does that for you, providing whatever UI

(maybe not even mentioning the fact that you're enabling it)

Do you have any evidence clients are doing this, or are you guessing?

No evindence, just saying it's a possibility

I highly doubt things will execute random ad-hoc commands

The spam I receive is 95% russian and about spam services

So I can assume its the same sender.