jdev - 2023-09-02

Are some of you interested to implement https://xmpp.org/extensions/xep-0466.html ?

Seems not that complex

>An ephemeral message is a <message/> including an <ephemeral/> tag in the urn:xmpp:ephemeral:0 namespace, with an attribute timer (xs:unsignedInt) indicating the delay in seconds, after which a message MUST be discarded. rebuttal: other people MUST NOT be able to tell me which messages i SHOULD keep

this is one of the shittier features other IM platforms introduced

this xep also uses the obsolescent "negociation" lol

it would be nice to be implemented

and i definetily look to have this in my client

Yes, for Movim it would be a nice addon :)

yeah its one of the things i am missing the most in xmpp

Why send with a timer instead of sending, running a timer, and retracting?

Because for retracting you need to be online

> Because for retracting you need to be online Maybe we just need server support for delayed sends instead ↺

ie send this message in X seconds

Also: retract this message in X seconds

That's built in right?

why need server support like this?

Then only your client would need to implement it, not everyone else's, plus it gives other features for free?

but it would suggest that the server needs to implement it. which makes it 1. unusable for p2p. 2. it would mean that the server can decide if they support it instead of giving agency to the people using the clients

plus of course not everything needs to be a server feature if it can be solved more simply

This also gets you the delayed send messages that other platforms have, that it can be used for delayed retractions is an added bonus

Doesn't https://xmpp.org/extensions/xep-0079.html have delayed delivery?

of course one could do this that way, but it sounds more complicated with a lot of edge chases

instead of simply communicating everything to the other client with one simple message

yep

> Doesn't https://xmpp.org/extensions/xep-0079.html have delayed delivery? Indeed, nice https://xmpp.org/extensions/xep-0079.html#conditions-def-deliver ↺

It's needing server feature vs needing client feature. You need either a feature on your server is a feature on all remote clients. Which is simpler to achieve probably varies by user

why hasnt been implemented though? the 0079 that is

I don't think so, not by the current generation of software

because i know there is also fastening that seems to be doing something similar to reactions but we opted for a xep specific to reactions

AFAIK fastening is over. I didn't dislike the model but it had too little value for most to support I guess

That's the impression I got at summit

Case of premature genericness?

so maybe same thing with 0079?

Zash: premature or just underappreciated depending on PoV I guess ✏

MSavoritias (fae,ve), I think it was implemented in older servers, but fell out of fashion for its complexity and lack of use.

or did they just advance things to Stable without implementations back in 2005?

Don't we still?

I've never got the impression that most xeps have any implemetations

Final being the one that actually requires implementations

I swear stable required 2 implementations

It was called Draft back then :)

> In order for a XEP to advance from Stable status to Final status [...] at least two implementations of the XEP must exist

Oh so we do have the ietf rule in there.... Just super late in the process and almost no xep gets that far

Unclear why anyone would want to push a xep to final so no changes can ever be made

yeah. and a lot of xeps that are actually supposed to be implemented or are are obsolete

also that yeah

Seems like a state that shouldn't exist

Stable is good

yeah

> Unclear why anyone would want to push a xep to final so no changes can ever be made So that people can actually rely on it ↺

and it should be easier to release new drafts

Instead we have something horrifying called "namespace versioning"

why is it scary?

And we often have implementations of Experimental :)

Once a xep goes to final you can update it, you just need a new xep number

isnt it supposed to be like that?

Things have drifted out of sync a bit

with namespaces

MSavoritias (fae,ve): every time the namespace changes it makes implemetations even harder

> Once a xep goes to final you can update it, you just need a new xep number This isn't the ietf ↺

singpolyma, that may have been the original intent, since RFCs work like that, but we don't seem to follow that anymore

I agree namespace bumps should be avoided whenever possible

How do I add luaevent if my distro doesn't have it packaged?

To prosody

moparisthebest: correct, the ietf is better

> Once a xep goes to final you can update it, you just need a new xep number a council vote actually :) ↺

> MSavoritias (fae,ve): every time the namespace changes it makes implemetations even harder why? you mean because you need to send to different namespace versions? ↺

MSavoritias (fae,ve): you have to look for all versions on incoming and either pick one for outgoing or disco somehow

When the schema is fundamentally different you might need this anyway so I understand the mechanism

But most namespace bumps are like "added a new attribute" or "made this attribute optional"

> How do I add luaevent if my distro doesn't have it packaged? xmpp:prosody@conference.prosody.im?join ↺

> But most namespace bumps are like "added a new attribute" or "made this attribute optional" well thats a different argument. i agree it shouldnt be taken lightly. but thats up to the council to vote it in no? ↺

I'm banned from it because jonas and MattJ were unable to answer for their misdeeds publicly

MattJ unable to answer, I challenged him to explain.

After 6-7 messages and no reply, I abused the bastard

And thus, got banned

sagaracharya: sounds like someone we should be really invested in helping with their problem. /s

i think we all agree that the xep process needs changes anyway though

I mean, it doesn't need to work the way I would have it work 🤷‍♂️

But definitely I release working code before I even think to draft a spec

me too.

i mean how else you would know it works? right?

> After 6-7 messages and no reply, I abused the bastard If you continue using this type of language I guess you'll be banned here as well soon.

Martin: Well, I know how things are going to proceed with MattJ being the owner

Facelessness over internet is not solvable

> Are some of you interested to implement https://xmpp.org/extensions/xep-0466.html ? > > Seems not that complex Mission Impossible 😉

https://www.youtube.com/watch?v=KlyLtJd-ArY

snarky comments dont help though 🙂

> snarky comments dont help though 🙂 🙂. So don't post snarky comments then.

I thought visualisation is necessary for certain people as they find it difficult to prefix `torsocks` to "hide" their IP. Not a fan of deleting messages but I'd get behind xep0466 tho. Pretty cool.

sagaracharya, hi and welcome. I trust since you have returned that you'll now stick to the XSF CoC.

sagaracharya: it was a response to Trung not you

> But definitely I release working code before I even think to draft a spec I agree, not everyone works that way but it seems to produce better specs in my opinion ↺

Chicken vs egg all over again :)

> sagaracharya, hi and welcome. I trust since you have returned that you'll now stick to the XSF CoC. jonas I have better things to do than talk to you.

sagaracharya: please refrain from this kind of a use in our channels, thanks

Ok, I'll resolve it with MattJ first, if he's willing to answer

Or just let it go and be happy

I feel like when you do spec first it's the edge cases that get missed

moparisthebest: Or MattJ can apologize and get even, and never use jonas to press people in this group and remove them when they fight back

sagaracharya: just stop and be happy

MattJ: Read the above and answer

moparisthebest, I suspect that implementation first has different issues. E.g. you might encode _your_ specific use cases, but miss others.

Zash: so it protects against premature generalization? :D I'm sold

In the end, some middle way might be best, i.e. write a PoC and document what it did, then submit as Experimental :)

Zash: yeah, I think getting real user feedback is useful, but then once you have enough go to experimental and expect more changes when a second or third implemetation hrppens

Hi everyone, does anyone here know of a client that lets you decide how many of the most recent messages to fetch? Is that even possible? I find I don’t open the Siskin IM app too often and always end up with like +2k messages being downloaded 🫨

You want to miss messages? Or you mean in public/large channels specifically?

Hmm, I hadn’t thought of it as “miss messages” before you said that. I guess in other messaging apps I don’t see it happening but it actually does happen in the background

soulcaramel: I think gajim lets you decide how many days of history you want to fetch from group chats / channels

@lissine thanks!

I’m learning a bit about the history of XML and JSON and wanted ask some of the xmpp contributors opinions on the data formats—being a contributor matters here since they deal with the data—and whether they’d prefer JSON over XML. This is a thought experiment question; I’m not a contributor and have no opinion on which is used

soulcaramel, I'd recommend against that.

Ok! I’m interested in hearing why since I’m looking into the technical details of xmpp to better understand it

FWIW my only experience is in web development so I’ve only ever used json

it does not matter much in my opinion, both are good enough for the job. If your messaging client is a success or failure will certainly not depend on JSON vs XML

Agreed

But if you go json you will inevitably find yourself reinventing the wheel, ie https://www.moparisthebest.com/images/jsonschema.jpg

Omg this made me laugh out loud

😂

And understood on json/xml not being the limiting factor