XSF Discussion - 2019-03-31

Added unbiased server list https://github.com/xsf/xmpp.org/pull/545

rion, xmpp:psi-dev@conference.jabber.ru?join is that still the room for psi? A user in the gajim room is apparently getting "Forbidden" when trying to join

O_o

maybe nickname conflict?

or invalid captcha input

captcha :(

yep we also suffer from spam

rion, I don't get prompted for any captcha btw, I manage to join. I'm not sure what that user is doing.. possible PEBCAK :/

pep.‎, hm I don't know why you weren't prompted. maybe you are already reigstered there. I'm now on Gajim and can't check

rion, Is there a place that user can join to get help from you directly? Or can you join gajim@conference.gajim.org? It's pretty hard to debug stuff from here otherwise :p

Is there any example of XEPs that are then overriden with other more specific XEPs, some kind of profile definition ✏

pep.‎, do you expect to hear "pep" ?

:)

I did have it in mind but I wanted to know if there were any others

404.city Support: can you update the logo? https://twitter.com/404_city/status/1110460013661880320

Hey stack overflow put up it's April 1st joke early too https://superuser.com/questions/1419573/snort-failed-to-parse-the-ip-address cc jonas’ :D

Non mobile layout only

yeah

nice

To answer my own question, 374 is a profile of 373.

Neustradamus, Does XMPP have a new logo?

"yes", the bits overlapping at the bottom have been corrected

The orange bits

A little change: https://commons.wikimedia.org/wiki/File:XMPP_logo.svg

Neustradamus, Ok (old tweets cannot be changed, but new ones will be with the new logo)

TIL xeps use prettifyjs, what's the JS in there used for? I would think the CSS file is enough to colorize xml snippets, but disabling that JS script makes colors not render

pep.: You seem to be answering your own question?

Yeah but why

What actually requires JS

... the XML syntax highlighter

I don't know why, it's always been like that.

probably because nobody dared to implement XML syntax highlighting in XSLT

Ohh, I get it now

I thought that was generated before, statically, I wasn't even thinking about xslt..

is one -1 vote enough to block the message correcting change?

yes

than thanks for blocking that Ge0rG , i feel there was no real discussion what is the best solution here

also if i remember correctly most client would do than exactly the opposite of what the XEP would say

personally I think both are equivalent, it's up to implementation details and people who won't want to change what they have and will argue the loudest now :)

In both cases things will break

If the concept is that a the payloads of a replacement message replace those of the corrected one, then https://github.com/xsf/xeps/pull/764/commits/a3dc32643c33282f474568f2100779f93a111deb seems consistent, becasue the top level attributes stay the same, including id

And then the replacement carrier message goes into the ether, like a chat state, having completed its task.

To me it's weird that LMC changes the whole payload inside fwiw

(or the whole stanza even)

to my knowledge nobody saves stanzas to local database

so the concept of replacing a stanza seems weird

In poezio that's what happens, in memory though, there's no saving to disk

yeah and then you have to do database operations that have nothing to do with the stanza

(well, the message itself yes, but not the stanza)

for me its obvious that the xep does not mandate to replace a stanza

that would mean the xep mandates some storage format of data in memory or database

Immutable history!

it just wants to say, to the user it should look like if the payload was replaced

lovetox, yeah that's also what I think it should be

also, with a precision that payload means <body/>

yes

so i would cast this stanza discussion aside

the real discussion is if it has pro/cons if we do one of both solutions

if you correct a correction stanza, does that mean you're replacing the payloads it's replacing?

What's the XEP again that recommends not putting too many things in a stanza at the same time?

There was a discussion and I brought up strong arguments in favor of the other way of doing it

But then everybody forgot about it and people moved on

but then that stanza would be replacing itself and collapse into a black hole

and also divide by zero

Zash, that's what usually happens no?

the problem is not the receiving side for me

I don't know

Hello NaN

if we do it like Kev proposes, and i send a correction, then i cant simply replace the text and forgot about that i just sent a *new* message with a unique id, an id for which i expect receipts

so i have to save that message, but not treat it as a message if the user again wants to correct

already thinking about this makes my head hurt

i also cant replace the id of the previous message, because i also expect receipts for that

the other way is much more straight forward to implement in my opinion

!xsf_Martin: you're quitjoining a lot

but maybe im overthinking this, maybe it doesnt really matter

what i wonder if one of the two solutions has pros for backscrolling/history loading

and also in no client its a true replacement

users expect to see the pre-corrected text

so its more like an addition

At Summit we discussed this, under the "mam2" topic

i would strongly lean to the solution that has better history/mam propertys

The plan was to give MAM another dimention for things like attachments, reactions, corrections

lovetox, yes and no. Poezio will no keep the original text if you have LMC enabled, (which I think is bad, but I have no clue how to make it on the UI). It will only show all messages (in an info window) if you configure beforehand that you want to see corrections

*that you want to see what's being corrected, to what, iirc. (I don't use this feature. When in doubt, I look at the xml_tab :-°

Zash, aggregation?

pep.: what you are saying is a sophisticated wording for 'poezio LMC sucks'

ah k

Ge0rG, I am not hiding it :)

Not trying to at least

pep.: that would be a thing you could do with that multi-dimentional thing

lovetox: my argument is that when receiving partial history, you maybe don't have the original message, but all the corrections.

pep.: basically flatten it a bit

Zash: I think the two dimensional MAM is orthogonal to which message to reference

but wouldnt always correct the same id then better

When going from the end I guess it's about the same

like if i receive a message from history, with the first correction i receive, i at least know what id i have to look for to get the original

Ge0rG: You'd reference the first level

and with the chain way, i never know if that was the last correction

it could go endless

archive[user][archive-id][payload-type][i] = stuff

Altho would that model allow correcting a reaction?

Can you look for XEP-0308 muc log archive from server and from client? Example: Test 1 -> Test 2 There are two entries in the log archive from server and from client? ✏