jdev - 2022-01-04

I would like to apply for membership and need to obtain a wiki account Username in CamelCase: xnamed Email: xnamedx@gmail.com Real name: if not necessary I prefer not to make it public in the wiki or web logs

The awful thing about matrix is that its really easy to do x-over-matrix but near impossible to do matrix-over-x without just being a homeserver

So it kinda spreads by basic nature

> The awful thing about matrix is that its really easy to do x-over-matrix but near impossible to do matrix-over-x without just being a homeserver Why's that

Because of the requirement to maintain the full room state for anything to make sense

Or, at least the auth chain

Once youre doing that, you're already basically a homeserver, so there's no half-assing it really

So many bad decisions in Matrix…

> Because of the requirement to maintain the full room state for anything to make sense That's how it makes sure no messages are lost isn't it

On jabber lost messages are common in my experience. One wrong circumstance and it starts failing

Yup

doge: Yes it makes sure messages aren't lost, in a sense. But i talso means that if your homeserver has a tiny difference in any validation alghorythm to any other homeserver that one of you will get effectively kicked out of any rooms you share, because the roomstate will be forked one that validation detail is triggered

You could add lua tables with a depth of like 1000 i think and then construct would defederate the room :D, there was also instances synapse would defederate and others would stay... it's all very finicky, either you have everything correct or it inevitably blows up

json tables... not lua

"Fail fast" It's preferrable to know something's failed. Unlike in xmpp where when there's a failure you get some messages, lose some, get some duplicates and whatnot, you end up having to ask your interlocutor what they received and what they didn't receive, so basically do the acking yourself

XMPP does its own acking... once your server acknowledges your message, messages get delivered or you get a delivery error. We also have positive delivery receipts.

doge: This isn't failing fast, it is more like an inherent design flaw, it means that every time one part of the federation can't handle a single message that the entire federation then kicks that part out

MattJ: > XMPP does its own acking... once your server acknowledges your message, messages get delivered or you get a delivery error. We also have positive delivery receipts. Still losing messages is almost the norm here unfortunately nephele: > doge: This isn't failing fast, it is more like an inherent design flaw, it means that every time one part of the federation can't handle a single message that the entire federation then kicks that part out Well what else would they do? Tolerate an error?

Are you asking me "How would this design be fixed" or "How would you propose to handle this in the current design"?

As for my part: I've never had any messages be lost in xmpp

doge, what server/clients are you using? Pidgin? :)

(I did however manage to make sure people lost messages they wrote to me in matrix :D)

MattJ: conversations, gajim

and do you get delivery receipts for the missing messages?

Matrix told me the joys of "message based html injection", that was quite fun to discover... the riot or element or vector client or whatever was absolutely horrible when dealing with their fancy formated html messages

MattJ: yeah I also sometimes get duplicates, although that's gone now I think

failled message delivery on XMPP ? which is also based on TCP ? 🤔

doge, in which direction are messages getting lost? From you to your contacts, or contacts to you?

MattJ: > doge, in which direction are messages getting lost? From you to your contacts, or contacts to you? Both

Do you or your contacts use multiple devices?

edhelas: It's possible of course, the transport protocol is not the only thing to touch the message ;)

MattJ: > Do you or your contacts use multiple devices? They do, so do I

nephele yes, it is possible, but I actually want to know how

Although I had messages lost even with a cobtact who didnt use multiple devs

Does your server have MAM and Carbons support enabled?

Heh... Renga still needs to implement MAM

edhelas: yes, it would be interesting to figure out

MattJ: mam perhaps. Although I've tried more than one server. Creep.im, draugr.de and then some. I found I actually had to have two accounts for when one server was down

doge, both are necessarily if you want a decent experience, and they are supported and enabled by default on practically all servers these days ( https://compliance.conversations.im/test/xep0313/ )

Dear Jabber / XMPP Devs, please take a look at this site and consider to make an entry for yourself: https://xmpp.work/all-listings/ ✏

If you see a delivery receipt, it means the recipient's client received the message. If it's acknowledging messages and not displaying them, that's a bad client bug, not a protocol issue

Also for it to reach that point, the message would be stored in the MAM archive, so cannot be lost

All clients I've used happend to be buggy then

all XMPP are buggy for sure

I've not heard of anyone experiencing this issue, so the common factor seems to be you, your clients or your server

MattJ: and my contacts'

As I explained, losing messages is pretty difficult to achieve

Right, all your contacts have you as a common factor :)

MattJ: ok shoyld I be using smth different than conversations? I think it's about the most popular client, would be strange if it was also the most buggy one

No, Conversations should be fine. I and many others use it all the time without such issues.

what are the chances this is some obscure OMEMO issue?

But it does require the server to be up to date with modern requirements (you can check this in the 'server info' section of the account details in the app, or at https://compliance.conversations.im/ )

MattJ: > No, Conversations should be fine. I and many others use it all the time without such issues. Do you talk to many people with direct messages? Omemo?

oh also creep.im has been added to some banlists, so some loss of connectivity is to be expected between creep.im and non-creep.im accounts.

jonas’: creep.im is dead now, yeah

So it was a good idea to have two accounts for that additional reason :)

doge, yes to both, my whole family use Snikket (the Android app is 99.9% Conversations)

MattJ: which server?

A self-hosted Snikket server (which is Prosody)

Oh, that may have been the reason

For good experience

I havent had a single message bieg lost here either. Multiple servers and applications. Thanks for the heads up about creep btw.

I'm wondering for MAM, the specification sais that a server for it may not be an XMPP server, sounds like there could be a specific MAM suplying server next to the client for local history storage or so? Does something like that exist?

nephele, an example I see is for clients to exchange history between each other, e.g. if you add a new client to your account and want to migrate past history to that new client

But I don't know of anyone actually implementing that, it would have some issues

That could be a possible case, I was wondering if someone made something that stores history locally /next to/ an existing client, in the client I could probably fairly easily querry this local store then and only ask the server for newer messages

You could, but 1) why? 2) it falls apart with E2EE

As a bit of background context: Renga did have local storing of chat history, but it was extremely messy (basically when the UI would get a new message and add it to the backlog it would also append it in the same manner to the local chatlog)

It falls apart with OMEMO, PGP or Ox should be fine. :)

Why would it fall apart with E2EE?

nephele: OMEMO uses forward secrecy so each message could be only decrypted once per key.

I don't really understand how that would be affected, is there something inherently which would prevent MAM working with OMEMO?

I haven't really looked at it much, but as i understand it if you have a session key to decrypt messages that key will work fine in the future to decrypt the same message again, so supposedly my client would have to store this key to decrypt backlog messages in the future anyway, I don't see how a local history store would conflict with that (as opposed to the history stored on the server)

nephele, storing every single key expecting to download the messages again, is pretty much equivalent to just storing every single message.

As you usually advance the key with each message (approximately).

Plus, your MAM server could be configured to have a short retention time, and then you won’t be able to go back in time any longer.

At JabberFR we keep personal archives for only two weeks, for instance.

As for my why: It seems like a much easier way to implement local message archiving and cut down on latency for backlog messages that I already have locally. (Would be the exact same codepath as MAM already would have anyhow :3)

Link Mauve: I don't know about you but i don't want to loose my backlog messages, ever. But that is also why I am on a personal server that can be configured as such

Cut down on latency... you imply making a direct connection to the archive?

What do you mean by direct?

I mean not via your normal XMPP connection

nephele, then relying on MAM on any random server storing messages forever is not what you want in your client.

My idea would rather be to have a server running on the same machine as the client that basically /only/ does MAM, as a provider for the local cache of the client

So storing the per-message decryption key without the message is a bit useless.

nephele, most clients use a sqlite database or a (bunch of) text file for that.

That way they don’t need to spawn a server.

What the on-disk store is is a bit beside the point, It seems to me to be an easy way to have the local history backed up without needing to have severall code paths in the client to deal with that.

Since basically: XMPP has specified a way I can get the backlog consistently, and I have to implement that anyway, it seems to make sense to use that for local backlog aswell, that way if the client ever displays for example more stuff about messages in the future it would also be visible from the local backlog stored messages.

Re http upload, the Expires header, what is it for? Is it also something the client has to pass in the PUT request? Or is it for the client to know when it expires, or both? And if the client doesn't pass it, what happens? Servers store that indefinitely? :P

(We worry about servers but do we worry about clients!)

pep., the headers are to be opaque for the client

pass them on, don't interpret them ✏

if you don't pass it on, the HTTP server may refuse your request

Ok well that isn't specified either iirc :/

why?

which part is missing?

why what

That the HTTP server may refuse the request, and that I have to pass the headers

It's implied, and yeah of course I see an Authorization header I get an idea, but it's not actually mentioned

hah

you're right

there's no word in the XEP which says that you have to pass on the headers

only that they exist, that you must validate them and do things with them, but not that you have to pass them on

pep., mind making a patch?

Sure

It's implied when it says I shouldn't pass other headers

But that's a weird way of saying I have to pass these

yep

needs better wording

> In addition to the Content-Length and Content-Type header the client MUST include all allowed headers that came with the slot assignment. Not this?

uh

yeah, that'd be it

The "headers are opaque to the clients", is that also commonly accepted?

In 6.

Can I also put that in there?

https://xmpp.org/extensions/xep-0363.html#upload

pep., you can add that to 7. (as a SHOULD NOT, I guess)

I'm actually curious why Expires goes through the client tbh :/

pep., probably S3

Really we worry about servers but not about clients at all

what is your concern with that regarding clients?

They can just skip that

Or extend it or..

skip what?

The header

that's their problem then

It's the receiving server's problem. They don't know what the XMPP server said

it's the HTTP server's problem

Then why is that header even sent from the XMPP server

to allow schemes where the XMPP and the HTTP server cannot or should not talk directly to one another

Trusting the client to relay

no

you'd not blindly trust the client

you'd sign the headers, obviously

using an HMAC or somesuch

Ah ok. What would that look like? More or less

(like the "http_upload_external" protocol from prosody does, though it doesn't use headers)

http_upload_external has a verification key which is (in version two) hmac(filename || content_type || size)

this is part of the URL

That's also specified somewhere?

here: https://modules.prosody.im/mod_http_upload_external.html

Ok

but it doesn't matter for the client

Sure

because it works within the boudnaries of '363

Thanks

if you wanted / needed to pass on headers like Expires, those would also need to be signed, e.g. by including them in an HMAC you pass through the Authorization header

but stuff like this allows the XMPP server to securely control parameters of the upload, such as lifetime, used content-type or even check the quota. and have the HTTP service be really dumb

("you" being the server side conglomerate in this case)

but all of this are implementation details of the server side. adding "you should sign your headers because clients are evil" to the implementation/security notes makes total sense though

I mean if we start considering servers evil we might want to do so for clients as well

we generally do ;)

Dunno. I feel like there's part of the community who has made a shift from considering clients evil to the opposite, and now I feel it's either one or the other :P ✏

right

I do not share that viewpoint, but YMMV and in the end, it doesn't matter. if you see something, fix something.

Here, pushed https://github.com/xsf/xeps/pull/1140

Ah linkmauve has already added a thing for multiple headers

I guess that shouldn't conflict (spec-wise) with my changes. But I can rebase on top of that if necessary

> edhelas wrote: > all XMPP are buggy for sure All xmpp devs are entemologists

That's why we like to leave bugs everywhere

Exactly

Alex, Ge0rG, sysops, have you read my message?

xnamed: sorry, say what?

> I would like to apply for membership and need to obtain a wiki account > Username in CamelCase: xnamed > Email: xnamedx@gmail.com > Real name: if not necessary I prefer not to make it public in the wiki or web logs

xnamed: xnamed is not camelcase, it will become Xnamed

It's ok

> The user account for Xnamed (talk) has been created. Please check your email

Ge0rG: thank you

xnamed: I think its mandatory to place your real name. However, you can do most things here without being a XSF member ralphm:

emus: I'm planning to change my real name in the future

emus: the real name is only mandatory for XSF membership, not for editing the wiki

yes, but it was stated to plan to apply

Ge0rG: I asked for a wiki account because I want to become XSF member

xnamed: If you prefer to stay anonymous you can still do many things incl. xep development, right?

xnamed, fwiw, changing the real name associated with the account is trivial

And nobody ever confirmed the realname was actually required legally for membership. Board just decided so ✏

been there had that done

It's not a big problem, I will use my real but in case I changed it in the future I will request changing it on the wiki too, is it okay?

Alex:

xnamed, back then I sent an email to the members@ list and made the corresponding pull requests myself, but you can also ask one of the sysops to help you with that, yes

That's fine; note that you don't have to use your real name for your wiki account, you just have to put it on your application each year

So you won't have to change anything. If you change your name, just put the new one on next years application.

> xnamed: If you prefer to stay anonymous you can still do many things incl. xep development, right? I'm already doing this

Thank you all 👍

Also the real name will be listed on our XSF website. There is a list of members with real names

Ok

And maybe someday there's be a rationale for why this is required

I guess because how you can have a legal entity for donations with anonymous people

The entity isn't anonymous

Board isn't anonymous

But why have a anonymous organsiation actually?

Why require fullnames?

I don't understand why we should build an anonymous organisation. Especially if we do communication. In that aspect it should be open. but we are getting offtopic

Open doesn't mean we should get rid of privacy ✏

Open doesn't actually mean much anyway.

(or it means too much)

but if its a organisation that is also a legal instance

You seem to be throwing random words in the air in hope that I catch them

yes but as an organisation it is also a legal instance

And also going in circles. I've already answered this

I dont think so

I think its impirtant to have transparency because otherwise random members can join and vote

The day the XSF gets there maybe they can start worrying about it. So far it's only idling members

some people are known only by their nickname here, and having their realname wouldn't help you at all

And no check is actually done whether the name is legal

making sure each member is who they pretend they are is useful. But that doesn't necessarily means "real" name

Like when bear was voted out because nobody knew them by their afk name.

It feels really wierd to be called by my real name in the context of programming in english, it's just always my nickname normally :D

So no I don't think it's justified to require fullnames. There's no legal basis for members (and is there for board? Maybe the chair?), or at least my question was never answered. (Because yes I asked and nobody cared)

xsf@ might be a more appropriate place to discuss the legal stuff of the XSF than jdev@

Sure, it just popped up in here.

But why do I care anyway, I'm no member anymore.

https://logs.xmpp.org/xsf/2021-11-04?p=h#2021-11-04-1345a93abcf14a57 (and surrounding discussion)

> pep. escribió: > So no I don't think it's justified to require fullnames. There's no legal basis for members (and is there for board? Maybe the chair?), or at least my question was never answered. (Because yes I asked and nobody cared) sorry, but this is just your perception. I also dont like to place my name, but I am still not an anarchist

Most of this doesn't matter. The state of Deleware allows anonymous members, but does not allow anonymous directors, so if we don't go ahead and get the names of members it becomes confusing if they decide to run for board later (you have to keep track of who can and can't run for board because they don't have their name on the membership list). It also doesn't matter if the XSF doesn't check if the name is legal or not. If the secretary of state in Deleware tries to revoke our non-profit status we could say "we required the name, but the person lied to us" and then it's their problem. It's just doing the minimal thing to make sure the XSF can retain its tax exempt status, which is good. As far as I know having names does not avoid multiple votes, we have other mechanisms (voting / the application where you'd need to list work you've done) for that.

"voting for members initially" I mean, obviously general voting does not avoid multiple votes :)

Yeah so.. only board is required to have fullnames public then.

By law, yes.

However, the board is able to decide the rules for membership and though I can't say exactly why they chose to require full names, I suspect it's because it makes it much easier to sort things out later if there are any conflicts.

> but I am still not an anarchist lolwat

Sam, fwiw, board membership doesn't even require XSF membership, hence the argument w.r.t. full names is kind of moot anyway -- you need to collect the information for prospect board members separately, in theory at least, anyway.

Sam, yeah and I am sure this is excluding potential members. I wasn't aware of the discussion Zash linked but that's yet another case

If the XSF doesn't care then that's that. But that's a good step backwards wrt inclusivity

it's not a step backwards, it's not a step at all ;)

Right, it was already there

But the multiple chats and refusals to change this isn't setting the track record nicely

aside: this is off-topic for this room, and unless you (general, not second person) actually works toward improving/fixing things, please avoid wasting the bandwidth of everyone here. Just saying "this is bad but nobody cares" isn't going to help anyone.

> pep. escribió: > If the XSF doesn't care then that's that. But that's a good step backwards wrt inclusivity Well, if not all agree to it doesnt mean "we" dont care. I think its a harsh statement

names

End Of Topic.

emus, afaict board sets what the XSF says ✏

xmpp:xsf@muc.xmpp.org?join would be the right place to discuss this and move toward progress. The room is also accessible for non-members, so those of you who don't already happen to be in there can join there.

jonas’, I merged #1135 and #1130 (from linkmauve and me respectively) into #1140 btw

Re 363

These should all be editorial changes

uh-uh

Maybe.

pep., https://github.com/xsf/xeps/pull/1140#pullrequestreview-843840558

Should I split it?

So that the rest goes in quickly

only the "in bytes" and the signing of headers I could be convinced to let go without passing by council

so I don't see value in splitting this

and it creates more work for me

Ok. I'll update the revision block then

thanks