jdev - 2026-03-06

And also here - https://github.com/dwd/Wimsy/releases/tag/v0.0.5 - still prerelease, but would welcome feedback.

when does it get quic/webtransport support?

I can give you an @xmpp.beer account for testing

Can WebXDC handle input files?

Like say, I upload a Ruffle widget and then attach a SWF file aswell, can the widget automatically load the user-provided file? (or does WebXDC not allow this to happen as of now)

Or is it just apart of the state update

You could cram it in the state update if it's not too big

What if it is big?

Like 5MB or so

Then it won't fit in a state update

If WebXDC supported setting up the widget with a file data supplied by the client (where it can do HTTP file download, OMEMO decryption, etc. etc.)

Then it would be easy to make loader apps like Ruffle to play with people, for example ✏

I wonder why they haven't done that

Why not just pack the file into the WebXDC?

seems it would be simpler to use that way

That would be much harder for a user to do

I mean I'm assuming telling a user to unpack a xdc file, put the file in, and then repack before sending would be pretty hard

I'm not sure in what way loading a SWF blob into a player that isn't aware if it will do anything useful. How does the SWF blob know about the state update protocol etc?

Then again in the WebXDC XEP, the client does upload the XDC file to the server

> I mean I'm assuming telling a user to unpack a xdc file, put the file in, and then repack before sending would be pretty hard I can probably make a single html file that lets anyone do this if there's a reason ↺

> Then again in the WebXDC XEP, the client does upload the XDC file to the server True. A specialized client could also do it before send if it wanted ↺

> I'm not sure in what way loading a SWF blob into a player that isn't aware if it will do anything useful. How does the SWF blob know about the state update protocol etc? I mean, you can either modify the player to hook into the SWF state (would be dependent on the file that is loaded) and send over updates, or just don't bother :P ↺

I don't think people would mind much about the lack of state updates from a generic loader ✏

But if you don't bother then what is the point? It's just a web view in your chat app with no integrations? Might as well be a link then why use WebXDC

Well sure, I'll give you a better example

How about an emulator that actually does hook into the game's state and updates the state with achievements? (RetroArch with RetroAchievements) ✏

Sure if it has some generic way to do that over many payloads it could be useful

You mean the client injecting a file into the WebXDC payload? ✏

Right

hi guys :) the other day i brought up a potential idea to allow muc users to see each other's mutual rooms in an explicitly opt-in way. the longer i thought about it, the less useful that particular method seemed to be. i'm doing more research into XEPs, and noticed 0194(user chatting), which lets users expose the rooms they're in with PEP, and 0316(MUC eventing protocol), which allows PEP to work in semianon rooms. the combination of these two would, i believe, achieve what i want; however, both specifications are deferred and have no known implementations. does anyone know why? was it just lack of interest, or were there technical reasons? (or is there a newer way of doing this now?)

Why would anyone care what other rooms I'm in?

> hi guys :) the other day i brought up a potential idea to allow muc users to see each other's mutual rooms in an explicitly opt-in way. the longer i thought about it, the less useful that particular method seemed to be. i'm doing more research into XEPs, and noticed 0194(user chatting), which lets users expose the rooms they're in with PEP, and 0316(MUC eventing protocol), which allows PEP to work in semianon rooms. the combination of these two would, i believe, achieve what i want; however, both specifications are deferred and have no known implementations. does anyone know why? was it just lack of interest, or were there technical reasons? (or is there a newer way of doing this now?) Will this just leak your entire MUC bookmark to a room? ↺

> Why would anyone care what other rooms I'm in? Discord feature ↺

Same with "mutual friends"

> Will this just leak your entire MUC bookmark to a room? no, ideally it'd be an explicitly-opt in thing, and 0194 specifically says that users MUST be able to only advertise a subset of their rooms ↺

> Why would anyone care what other rooms I'm in? i personally find it helpful to identify users i don't know very well, especially if they frequently change their avatar and/or nickname, to be able to see what other rooms they're in (and ideally any other nicks they use there, though 0194 doesn't help with that part). making it explicitly opt-in ensures users who don't want that don't have it by default ↺

its a pretty common feature on other IMs

Why not hash the room IDs

And compare

This is a good feature for stalkers, because they can join the rooms they're not in but you are in

Well if it's a semi anon room the whole point is you shouldn't know who they are. Otherwise do the same as every other chat protocol ever and let participants see their id

> Why not hash the room IDs what exactly do you mean? like providing a hash of the room URI in the node instead of the URI itself? i'd be fine with that as well, since it'd still give me my mutual room functionality ↺

If its just for figuring out mutual rooms, you can hash the room JIDs (with some salt per-stanza and order of the JIDs randomized, just in case)

>> Why not hash the room IDs > what exactly do you mean? like providing a hash of the room URI in the node instead of the URI itself? i'd be fine with that as well, since it'd still give me my mutual room functionality Hash of the room ID, Like sha512("exampleroom@example.com" | salt) ↺

A client can just hash their entire MUC bookmark and check against the hashes you've advertised, to check for mutual rooms ✏

And also stops them from joining rooms they don't even know yet

Bloom filter. "This user is *probably* in the same room as you" 😉

> Well if it's a semi anon room the whole point is you shouldn't know who they are. Otherwise do the same as every other chat protocol ever and let participants see their id sure that's why this is an opt-in thing. most people i know have little use-case for semi-anon beyond hidng the JID to prevent dm spam and such. at the very least, i can be reasonably confident for 99% of users that the guy in two mucs with the same name and avatar is the same person, but i can't be sure that one of them isn't just an impersonator, and i can't be sure that the guy with the same avatar but a different nick is the same guy, especially not in a way that'd be easy to implement in a UI. for people who don't mind confirming what most people already know by intuition, these XEPs would be nice to have ↺

> If its just for figuring out mutual rooms, you can hash the room JIDs (with some salt per-stanza and order of the JIDs randomized, just in case) yeah this would be perfect. i wouldn't personally mind sharing the URI itself, but i definitely agree a lot of users would prefer to just send the hash. the XEP could be amended to say something like "one of <uri/> or <hash/> MUST be present" ↺

This design is better than XEP-0194, because you're not inviting random people to harass you everywhere ✏

yeah i definitely agree the hash is a really good idea :D

though i'd like to reiterate my questions about whether 0194 and 0316 were never implemented for lack of interest or technical reasons. i guess i'd consider the hash thing a technical reason for 0194, though i see that less as a blocker for implementing 0194 and more as a blocker for end-users enabling it. still unsure about 0316; i haven't done much reading on pubsub/pep yet

If there is a xep that wasn't implemented then the question I would have is why does it even exist. If even the author couldn't be bothered to implement it it seems more like a hypothetical than a spec

i've noticed a number of XEPs with few to no implementations which i would've loved to see, but apparently not even the author cared enough to make a reality 😔

maybe xep submissions should be required to have a proof of concept implementation 🧌

> yeah i definitely agree the hash is a really good idea :D Also BTW why pep anyway ↺

Why not just query the user telling them "are you in any of these rooms?", and give them a list of URI/hashes

Then it would be even better, people wouldn't save the list of hashes and compare it against a giant list of known MUCs

well for me its mostly because the XEPs to do what i want already exist and happen to use PEP. for the authors, i think its mostly that the goal was a series of XEPs implementing functionality akin to discord's rich presence(the same framework is used for music and games, for example), rather than a mutual room thing specifically

The XEP is from 2008

I don't think Discord existed back when this XEP was made

yes this is true. i didn't mean to imply that their reference here _was_ discord, just that both achieve similar goals in terms of providing rich information regarding users' current activities

> maybe xep submissions should be required to have a proof of concept implementation 🧌 this but seriously ↺

> Sure if it has some generic way to do that over many payloads it could be useful Do you know where the webxdc devs are? ↺

Cynthia: https://webxdc.org/

snit, XEPs do need implementations to advance. But Experimental ones are just ideas (or can be).

Also, the count of implementations in the XEP listing only shows _known_ implementations (via a DOAP file) - there could be undeclared implementations elsewhere

mind you i was mostly joking when i suggested that. i see merits to such a requirement, but i'm not convinced its actually a good idea in practice

It would be another barrier to submission, and would discourage community input (since one person/group has to do a whole implementation before getting outside opinions)

Theres significant pros and cons. The pros include being sure it’s implementable, and at least one person is motivated to do so. The cons include that once there’s a working implementation history tells us that people can be very resistant to improving the design because “it works and is deployed”, and we’ve had multiple instances in the past of subpar things persisting because there was an implementation already.

I lean on the side of the damage of requiring it being greater than the damage of not.

> It would be another barrier to submission, and would discourage community input (since one person/group has to do a whole implementation before getting outside opinions) If no one has done an implementation how can anyone possibly comment on if the thing will work? Even the author can't know in such a case ↺

Honestly I prefer subpar things that work to ideas for things that don't

Like is/was vcard temp gross? For sure. But it supported the ecosystem's needs for a very long time and I'm happy for it

And how could anyone know whether vcards are possible without an implementation! 🙄

> Honestly I prefer subpar things that work to ideas for things that don't this, I've never seen 1 spec no one ever implemented where it was thought out enough to actually implement and that not XSF specific or a criticism of anyone, it's just you inevitably run into things you didn't think about during implementation ↺

And that's why implementations are required for advancement, but just documenting an idea doesn't need 100% completeness

a spec without implementation is someone posting "it sure would be nice if someone did X" ok... do it?

I'm always weirded out by statements like "I'm writing this xep because I'd like someone to implement this feature" or "I'm submitting this xep because I'd like to start work on a prototype soon". All feels very cart before the horse

Or "here is my idea for what I intend to do and how I intend to do it - does anyone have ideas/opinions?"

> And that's why implementations are required for advancement, but just documenting an idea doesn't need 100% completeness sure, and just documenting an idea doesn't need submitted as a XEP ↺

> I'm always weirded out by statements like "I'm writing this xep because I'd like someone to implement this feature" or "I'm submitting this xep because I'd like to start work on a prototype soon". All feels very cart before the horse :1000: ↺

> Or "here is my idea for what I intend to do and how I intend to do it - does anyone have ideas/opinions?" yep, perfectly reasonable to do outside of submitting a XEP ↺

moparisthebest, you can have an idea that you’d like to implement at some point, write a protoxep to jauge interest, iterate a bit, and have an experimental XEP with no implementation with plans for it

and if the experimental XEP is not perfect (never is), you iterate, but I fail to see why that would be a problem

I think the difference here is really just the acceptance threshold for Experimental

It's just a weird backwards way to do things

> > Or "here is my idea for what I intend to do and how I intend to do it - does anyone have ideas/opinions?" > > yep, perfectly reasonable to do outside of submitting a XEP To be fair, this is partially why I’ve got some stuff up at https://github.com/swift/protoxeps , but it’s not really compatible with the way the XSF thinks its IPR works.

i wonder if XEP-0143 should be updated to reflect expectations (or lack thereof) on whether protoxeps and experimental xeps should have implementations. when working on my own protoxep, it wasn't exactly obvious to me whether i should already have one before submission, whether i should wait until its accepted, or whether the xsf doesn't actually care one way or the other

The XSF process does not care. Council members may have opinions

A prototype will never hurt you and it will certainly help in many cases

then imo it should explicitly say that, just so its absolutely clear to newcomers

Well, Council members may have opinions, but they’ll follow the XSF process, which is to not require it. :)

XSF process demands council to judge if a XEP is implementable though, obviously that's easier if an implementation exists

indeed. And any member can veto any new xep for any reason. though of course if they do it for unpopular reasons they won't get reelected I'm sure

> indeed. And any member can veto any new xep for any reason. though of course if they do it for unpopular reasons they won't get reelected I'm sure XMPP election? :o ↺

Cynthia, Council are elected by XSF members, if that's the peice you were missing. If you're in this room, you should probably consider applying to be a member.

now why would I?

Cynthia, A warm a fuzzy feeling of helping to manage the XSF?

I had a question

Should blocking messages and stuff be done on the client or servers

I'm working on this draft XEP where a user can block people based on relation (subscription status, or in a MUC context, affiliation/role) ✏

both

Its really hard to write filters on clients like Gajim than it is to write them on Prosody

Blocking can be done on either, but it's more efficient to handle it on the servers.

I'm already having a headache with clients' codebases

Tell me about it. I don't want to look at mine.

1:1 can be done by server or client, MUC can only be done by client

Yeah, MUC can be done by the client or MUC server

moparisthebest, I think MUC could sensibly be done on the server, though it might involve the server having to track MUCs much more than they do at present.

more than the not at all they do now? yes :P

Clients aren't designed to filter messages before they're handled by the rest of the program, I've seen

And that would be a giant pain in the ass to work around

but even then it falls apart with a future SCE encrypted muc

clients can easily filter messages wherever they want

You know I meant codebase

yes the thing that can be easily changed

I know why blocking command was done on server-side because it is dreadful trying to filter messages before the whole client receives it

> yes the thing that can be easily changed Heh, have you heard of code debt ↺

A flaw can gather "interest", and therefore take much more effort to solve over time than if it was solved right away