Post B0oULyWP5KzfnvdO2i by kris@outmo.de
(DIR) More posts by kris@outmo.de
(DIR) Post #B0oULkkmH6An6SFfVI by Lautaro_Ferrero@mastodon.social
2025-11-28T02:58:46Z
0 likes, 0 repeats
Ustedes creen que a los clientes #XMPP les haga falta una opción para hacer encuestas en los grupos/salas? Piensan que necesite algo así? Abro debate.
(DIR) Post #B0oULmYRZvUmgmUqYa by debacle@framapiaf.org
2025-11-28T07:59:39Z
0 likes, 0 repeats
@Lautaro_FerreroSi, falta. Ahora (ab) usamos Message Reactions, pero es una solución transitoria.
(DIR) Post #B0oULnlb4VbwRrerhI by nicoco@pouet.pas.la
2025-11-28T08:33:10Z
0 likes, 0 repeats
@debacle @Lautaro_Ferrero @John_Livingston implemented it in converse.js/prosody for #peertube It would be nice to standardize, I would be happy to bridge polls with https://slidge.im (yes, shameless plug).
(DIR) Post #B0oULoTCSOUOd63gf2 by John_Livingston@mamot.fr
2025-11-28T08:55:19Z
0 likes, 0 repeats
@nicoco Sorry, i speak only french and english. I don't understand previous messages.Yes, i have implemented polls. All clients can vote and see the result. I have a Prosody module for the backend. And a ConverseJS plugin to enhance the front.I plan to create a XEP, but i can't say when. Too busy...But you can check my technical doc:https://livingston.frama.io/peertube-plugin-livechat/technical/polls/index.htmlCode is AGPL-v3, so feel free...@debacle @Lautaro_Ferrero
(DIR) Post #B0oULp5q8jOiYw8XtA by nicoco@pouet.pas.la
2025-11-28T11:48:03Z
0 likes, 0 repeats
@debacle @Lautaro_Ferrero Non-authoritative (I am nobody) comments:- Replace `<x-poll>` with a XEP-0004 data form, no need to reinvent the wheel.- Replace the custom IQ flow by a XEP-0050 adhoc command flow, some clients have generic UI for that (eg @gajim or @cheogram).- (maybe) use XEP-0428 fallback indication for supporting clients to strip the body.More work! Incompatible with you not having time, I know. :o)Thanks for your work on that @John_Livingston ♥#xmpp
(DIR) Post #B0oULpvb2InX9SLsYq by larma@mastodon.social
2025-11-28T13:20:43Z
0 likes, 0 repeats
@nicoco @debacle @Lautaro_Ferrero @gajim @cheogram @John_Livingston Here's my take:- Don't use data forms or IQ (also not adhoc) and don't require active MUC support- Use regular messages (potentially with fallback) both for initiating the poll and for voting- Make clients do the summing up and enforcement of poll rules (similar to reactions)=> This would mean polls can also work outside MUCs (MIX, direct message, anything else) and when using end-to-end encryption.
(DIR) Post #B0oULqlhuYTvl4jUmm by nicoco@pouet.pas.la
2025-11-28T14:43:49Z
0 likes, 0 repeats
@debacle @John_Livingston Good point about E2EE @larma (I don't see the point of polls in direct messages though)No need for server-side support would be nice, but then you need to make sure that (a) MAM retention is sufficient and (b) clients actually enough history messages, right?Rule enforcement by clients is fine for private groups, but I don't think it's a good fit for public ones.Data forms in messages are possible, why not use them?
(DIR) Post #B0oULrbSo7skLawpSS by Goffi@mastodon.social
2025-11-28T19:50:32Z
0 likes, 0 repeats
@nicoco @debacle @John_Livingston @larmaArg, I've missed several messages from larma that I've seen later (due to how Mastodon works). I think we need server support. What about polls with hidden votes? Poll when we can see result only after it's finished?Anyway, we should probably first start by set the requirements before proposing a solution, we clearly have different views on the subject.
(DIR) Post #B0oULsV7TCOx8CzHCy by debacle@framapiaf.org
2025-11-28T20:19:41Z
0 likes, 0 repeats
@Goffi @nicoco @John_Livingston @larma Maybe we should start by having a look at prior-art and check the properties of other poll mechanisms.E.g. fediverse/Mastodon polls are, AFAIK, secret to the public and the initiator of the poll, but open to the initiators server? They can be single-choice or multiple-choice, but not weighted choice? The temporary result is visible immediately, not only at the end of the poll, which is not always desirable. You can only vote once, but everyone can vote?
(DIR) Post #B0oULtYhXMrQPbfeQi by debacle@framapiaf.org
2025-11-28T20:25:11Z
0 likes, 0 repeats
@Goffi @nicoco @John_Livingston @larma OTOH, votes in Debian (by email) have weighted choice and the result is only published after vote period. Only registered developers can vote. People can vote multiple times, but only the last vote counts. Votes are PGP-signed and -encrypted.For other polls it makes sense to vote in the open, e.g. when voting about the date of a meeting or similar. This is what Framadate is doing. (They have various options, didn't check.)
(DIR) Post #B0oULuIQnLRMhR4Ai0 by larma@mastodon.social
2025-12-01T11:44:15Z
0 likes, 0 repeats
@debacle @Goffi @nicoco @John_Livingston In decentralized or end-to-end encrypted systems, we mostly see the approach where everyone with access to the poll can see every vote immediately. This is mostly for technical reasons, as everything else almost requires centralized components and breaking e2ee.The other approach is centralized voting, which allows for a variety of options (publish results only after poll end, don't reveal individual votes, don't reveal who voted, ...)
(DIR) Post #B0oULvEZJBwdbkGbKK by larma@mastodon.social
2025-12-01T12:03:14Z
0 likes, 0 repeats
@debacle @Goffi @nicoco @John_Livingston Mastodon is in fact the centralized sort. The poll is hosted on the server of the person creating it and when voting, the local server will send a note to the hosting server, which will then send an update about the new poll status to all subscribers. Technically, a server could delay sending out the update and only reveal the poll results at the end of the poll.
(DIR) Post #B0oULw3cFOmIA49MtU by larma@mastodon.social
2025-12-01T12:14:12Z
0 likes, 0 repeats
@debacle @Goffi @nicoco @John_Livingston I think this shows there's use-cases for two different approaches:- A server-less, message-based poll, supporting e2ee- A server-based poll/vote. I could imagine this to use PubSub, which would allow for all kinds of things, read/subscribe results (either live or at end of poll), cast (publish) votes (either readable by everyone or just the server and your own clients). It then needs a way to link such a hosted poll from a message.
(DIR) Post #B0oULwqXJVuSbn2R96 by kris@outmo.de
2025-12-01T12:35:10.633767Z
0 likes, 0 repeats
@larma @debacle @Goffi @nicoco @John_Livingston The serverless option that works with e2ee is already available with WebXDC, it just needs more client adoption.
(DIR) Post #B0oULxbgUDciy165dQ by larma@mastodon.social
2025-12-01T12:47:24Z
0 likes, 0 repeats
@kris @debacle @John_Livingston @Goffi @nicoco WebXDC is not a poll in the chat, it's an app shared in the chat (that may be a poll app). From protocol-side, those are completely different things. And, AFAIK, current XMPP WebXDC implementations do not use e2ee.
(DIR) Post #B0oULyWP5KzfnvdO2i by kris@outmo.de
2025-12-01T14:48:03.272300Z
0 likes, 0 repeats
@larma @debacle @John_Livingston @Goffi @nicoco Afaik they pass messages through the chat which should also work e2ee. The way they do that is very similar to what you propose, just the UI is more flexible, which is IMHO good.
(DIR) Post #B0oULzHYG2hwA9h2X2 by larma@mastodon.social
2025-12-01T15:03:04Z
0 likes, 0 repeats
@kris @debacle @John_Livingston @Goffi @nicoco Old OMEMO (that afaik all WebXDC compatible XMPP clients use) only encrypts the body. In WebXDC updates, `update.info` is mapped into the message body, encrypted and displayed inside the chat, but all other parts of an update remain unencrypted (that is `update.payload`, `update.document`, `update.summary`). See https://webxdc.org/docs/spec/sendUpdate.html what each of those are meant to be used for.
(DIR) Post #B0oUM0BCv7E8wljUHY by Goffi@mastodon.social
2025-12-01T15:09:07Z
0 likes, 0 repeats
@larma @kris @debacle @John_Livingston @nicoco as I've said above, the goal is not to make sandboxed application, otherwise why even bother with specifications and XMPP?What I'll do with my CLI frontend with a WebXDC poll? Parse random HTML? Interpret JS? Run an headless browser?The goal of specification is to have interoperability, we don't have that with WebXDC.Don't take me wrong, WebXDC is cool and has its use, but it's not a replacement to proper spec.
(DIR) Post #B0oUM11fm3C7ZUHO3k by kris@outmo.de
2025-12-01T15:14:42.356093Z
0 likes, 0 repeats
@Goffi Your TUI client can interpret the messages passed by the WebXDC just fine and show them natively. Of course you then need to hard code certain known webxdc app behaviour in the TUI client, but that is a general issue with hardcoding such features that are IMHO better served by embedded micro-apps or bots.@larma @debacle @John_Livingston @nicoco
(DIR) Post #B0oUM2IN3S95VZ6Ej2 by larma@mastodon.social
2025-12-01T15:22:04Z
0 likes, 0 repeats
RE: https://mastodon.social/@larma/115644951905046144@kris @debacle @John_Livingston @Goffi @nicoco As I explained before, it's not reasonably possible to interpret WebXDC messages natively, because there is no standard for them. As WebXDC apps get updated, it's not possible to hard-code them (the next version will then simply not be considered the same anymore). It just makes sense to properly standardize things, which is why we do XMPP in first place. We can still make it such that WebXDC apps can send messages compliant with a new poll XEP.
(DIR) Post #B0oUM3JpFWu4gMmudE by kris@outmo.de
2025-12-01T15:34:52.549534Z
0 likes, 0 repeats
@larma @debacle @John_Livingston @Goffi @nicoco You are looking at the issue backwards. The existing Webxdc apps don't matter, what matters is the Webxdc XEP which specifies a very flexible and e2ee compatible message passing format that can be used for features like polls and having the javascript GUI is just an added benefit and a convenient fallback for other clients.
(DIR) Post #B0oUM4HNg6Xff4eTSa by larma@mastodon.social
2025-12-01T15:39:30Z
0 likes, 0 repeats
@kris @debacle @John_Livingston @Goffi @nicoco You mean, a new "standard" that's not WebXDC and largely incompatible with it? Who is going to adopt it? The only reason why WebXDC got adopted in XMPP in first place is the catalog of apps conveniently created by the deltachat community.
(DIR) Post #B0oUM5AgMUmIQaWdeq by kris@outmo.de
2025-12-01T15:51:59.607531Z
0 likes, 0 repeats
@larma @debacle @John_Livingston @Goffi @nicoco No need for a new standard, just use the existing WebXDC XEP and implement native polls on top of that. You get instant adoption of your poll feature in all WebXDC supporting apps that way.
(DIR) Post #B0oUM5Ymus3ndLntEO by Goffi@mastodon.social
2025-12-01T15:12:10Z
0 likes, 0 repeats
@larma @kris @debacle @John_Livingston @nicoco from a user perspective I understand that WebXDC looks like a one -size-fits-all solution, but from a developer perspective, trust me, it's not.
(DIR) Post #B0oUM65Oxc9FGV3w48 by larma@mastodon.social
2025-12-01T17:06:10Z
0 likes, 0 repeats
@kris The WebXDC specfication says, that WebXDC apps need to get a way to send 6 different types of update properties (described here: https://webxdc.org/docs/spec/sendUpdate.html). The main thing goes into the payload property, but what exactly goes there is up to the WebXDC app and also is a JavaScript object.This is why, if we'd want to allow using WebXDC as fallback, we'd need to create a new, incompatible WebXDC+XMPP specification that allows WebXDC+XMPP apps to send XMPP payload (with specific restrictions).
(DIR) Post #B0oUM7DEly0gl5jhuy by larma@mastodon.social
2025-12-01T17:08:54Z
0 likes, 0 repeats
@kris Only then could WebXDC+XMPP apps opt to send some payload that follows a standard and that would be sent over to other clients in a standards compliant way even if they don't support WebXDC+XMPP.But this wouldn't help with any of the existing WebXDC apps, because none of them would be compatible with this new specification. So we would start with 0 compatible apps and for XMPP client developers it would be as easy to implement things natively as it is to create a WebXDC+XMPP app.
(DIR) Post #B0oUM8NYR5rCNNZSdc by kris@outmo.de
2025-12-01T17:18:59.490755Z
0 likes, 0 repeats
@larma No, you are still looking at this in a totally backwards way. Existing Webxdc apps don't matter, all that matters is what the client that starts the poll sends. This is true for all WebXDC apps, but especially if you want to implement an additional native representation of the poll messages in your app.
(DIR) Post #B0oUM9XW7XQ7yZEvo0 by larma@mastodon.social
2025-12-01T17:27:57Z
0 likes, 0 repeats
@kris I understood that this is your idea. That's what I call WebXDC+XMPP apps (which are different to existing WebXDC apps). Just to be clear, that is not WebXDC and is not compatible with the existing WebXDC specification.And I doubt a lot of app developers would go forward and create such a WebXDC+XMPP app (instead of implementing the feature natively in their favorite XMPP client).
(DIR) Post #B0oUMAglqcPtXYZprs by kris@outmo.de
2025-12-01T17:35:47.432541Z
0 likes, 0 repeats
@larma no, why would this be incompatible with the webxdc standard? And existing webxdc apps could be easily enough used as a base for this with minor changes.I guess what you don't want is to have the native app pull the necessary data out of the in-chat webxdc payload which is not xmpp native? I understand that this is a bit iffy from an xmpp purist view, but I see no reason why that wouldn't work and if you know what the webxdc app sends (which you do, because you wrote it yourself), you can do that rather easily without a javascript interpreter or such.
(DIR) Post #B0oUMBia1NSSjSQnKK by larma@mastodon.social
2025-12-01T17:59:14Z
0 likes, 0 repeats
@kris let's say I create a XEP for polls in XMPP. Next to implementing that XEP in my XMPP client, I could deliver a WebXDC app, but that app wouldn't be able to speak the XEP directly, but rather speaks something non-standard that my app understands. Good for me, but how are clients that are not my client going to interpret the non-standard thing sent by the WebXDC app? We need the WebXDC apps to speak standard protocols, but that's just not possible with the official specification.
(DIR) Post #B0oUMCvNXHI2TRQWum by kris@outmo.de
2025-12-01T18:16:01.868588Z
0 likes, 0 repeats
@larma Well, the entire point is that you don't need the XEP for polls. And IMHO individual XEPs for such highly specialized features are a bad idea. And from a client developer perspective it really is no different if they need to implement a specific polls XEP or make the client understand the Webxdc payload for specific webxdc apps (or just implement a WebXDC viewer :neocat_fingerguns: ).An possible alternative would be to do it similar to Telegram/Discord and have XMPP support in chat dataforms that bots can use to display buttons and input fields etc. I think there are already some parts of that in various XEPs.I think the general extensibility of XMPP via XEPs is good, but it should be for defining the pipes, not the content. Polls are content, not pipes. WebXDC takes it maybe a bit too far with that idea, and the opposition of the JS haters was clear from the start, but the general idea to not pre-define rigid features in XEPs is good.
(DIR) Post #B0oUME2rMwrtwvw1DM by larma@mastodon.social
2025-12-01T18:23:55Z
0 likes, 0 repeats
@kris It's not about JS haters, it's just plain impossible to implement WebXDC in some context, including web clients. If we were to adopt WebXDC as a standard in the XMPP network, it would imply deprecation of web clients.Standards are so that different clients are compatible. If we don't agree on a standard (call it XEP or something else) for the specific WebXDC app (incl. version) used in the XMPP network for poll, than polls won't follow a standard and won't interoperate.
(DIR) Post #B0oUMEzhq9wKtRT0wC by kris@outmo.de
2025-12-01T18:29:47.434443Z
0 likes, 0 repeats
@larma To my knowledge, DeltaChat supports WebXDC also in their webclient. It is a bit more tricky to do securely, but not impossible.It would be easy enough to agree on a base WebXDC app for polls and implement understanding those payloads natively. And if you want to do some improvements, it is much easier than trying to change the rather static XEP.
(DIR) Post #B0oUMGCrKk3UeWd24u by larma@mastodon.social
2025-12-01T18:38:38Z
0 likes, 0 repeats
@kris I am not aware of a DeltaChat web client. It's not linked anywhere on their website or https://cosmos.delta.chat/Are you sure you are not referring to their desktop app, which, although web-based, can do more than a regular web client can do?
(DIR) Post #B0oUMHDbZSFJn7z8sa by larma@mastodon.social
2025-12-01T18:02:36Z
0 likes, 0 repeats
@kris And that is fine. WebXDC update messages were never meant to allow apps to speak a standard. It was meant to allow apps to speak to themselves (or instances of themselves running on another device). Standards only exist to allow communication between different apps. In other words: WebXDC is not the tool of choice here. Something else could be done to allow for this, but there really isn't sufficient interest from the XMPP developer community to do such thing at this point.
(DIR) Post #B0oUMHJHEMmc4idfii by kris@outmo.de
2025-12-01T18:45:17.412924Z
1 likes, 0 repeats
@larma Well, it exists, see: https://delta.chat/en/2025-05-22-browser-edition and they also posted a blog post that includes difficulties with WebXDC apps in that environment: https://delta.chat/en/2023-05-22-webxdc-securityBut, IMHO it is not that WebXDC apps don't run in browers, the question is can you sandbox them sufficiently. And that security question can also be solved in different ways without a sandbox.