XSF Discussion - 2022-01-10

larma: Have you already looked here? - https://about.psyc.eu - http://www.psyced.org/

https://news.ycombinator.com/item?id=29871358

just saw that too :)

:)

And it didn't took that long for the Matrix guy to say how bad is XMPP :p

Are polls (i.e. multiple choice votes) somehow doable with some existing XEP?

Only thing that would spring to mind for me would be the forms extension plus custom server-side logic. But I think only gajim really supports forms…

phryk: yeah, that's about it.

There is the quick action xep or something

basically implement Message Reactions and do polls with emojis :p

Quick response* xep-0439

MattJ i'm interested by your "account access delegation" feature indeed :)

More details soon :)

such teasing

(But no public client supports quick response, AFAIK, though I did an implementation in slixmpp)

edhelas, haven't formally signed anything with NLnet yet, so it feels premature to promise things until then. But it's no secret I've been wanting to improve this (account access and device/client management) for some time :)

edhelas, yes, saw the one person with the bad understanding about e2ee and key exchanges. too bad that this matrix per-user e2ee and the matrix feature to _share keys_ with other clients lead to this https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-40823

Zash, Broadly speaking, yes, any fastenish thing needs "deep" work on the MAM storage layer. Also any Inboxish thing, which is required (I think) for thin web clients to be efficient.

phryk, There's some bits of what you need for polls. But I think ideally we need not only forms, but "updatable messages" (or microapps), where a pubsub update can update the rendering of a preexisting message. So you'd present a poll (as form? with quick response? something else?) and by "magic", responses to the form would cause a pubsub event to update your client's view of the message. Perhaps?

dwd, pubsub can already be used for autoupdating views of ~some data~?

mathieui, thanks, that looks like it'd be a solid fallback for input even if forms end up broadly adopted.

> Isn't that Jabber? Haven't heard of XMPP in a while.

:D

:D

phryk, No, or at least yes but nothing in the standards for it.

phryk, If we had all the budget in the world, I'd do polls as sandboxed HTML+JS with APIs for pubsub publishes and events. But we don't have *any* of that beyond pubsub itself. :-)

oh god, please no js in xmpp.

if I had all the budget in the world I'd kill HTML+JS with fire like the cancer that it is

phryk, Oh, we're in daydream mode, right, so we can have them signed and you can trust only certain publishers or something.

js in xmpp is more like nightmare mode

kurisu, Why? Genuine question.

dwd, still, i don't want a goddamn browser engine in my client in order to be able to participate properly ::F

phryk, It does make things pretty heavyweight, yes. If essentially any message could spawn an entire HTML+JSS sandbox environment, it'd put Chrome to shame.

if xmpp integrates js, I'll drop it like a hot radioactive potato.^^

holy smokes what happened here

dwd, because it's effectively google's proprietary platform at this point. Not to mention the browser which is supposed to be just an http client + a viewer of some goddamn formatted text with forms now takes more to compile than the entire rest of my distro combined - if this isn't bloat, I don't know what is. Note how I say *the* browser because there's hardly any difference between them at this point, it's all a proprietary platform of google and its evil friends

kurisu, OK, but the notion of combining a display language and a scripting language with a constrained API, packaging up microapps into messaging itself is OK, or not?

no?

that sounds like the same misdirection the web took

jonas’, It did make the web very useful, mind.

also very misuseful

jonas’, And we wouldn't be running about making XMPP web clients with video calling if it hadn't taken that path.

instead, we'd polish the calling functionality the clients already had a decade ago

jonas’, That's probably wishful thinking. WebRTC didn't exist back then, yet we still had largely non-functional and non-interoperable calling then.

maybe

jonas’, Video calling, in particular, was basically borked. We had voice, though.

dwd, so integrating some kind of scripting language is a massive barrier for application development

you need runtimes for that language on all platforms (the mobile and web ones will be extra fun to deal with), and that needs to be sandboxed properly

jonas’, I can see that. Especially as being the community we are, we're have to pick something insanely esoteric.

I think the sanest choice would be webasm.

I rest my case.

cut away all the javascript cruft, go right with webasm asa runtime.

it should provide all sandboxing and there exists lots of tools to compile to it

it's supported by browsers

it should be usable on mobile one way or another

I don't like the taste of microapps still.

it's not how I (want to) use IM.

but *if* one would want to do it, webasm with access to the message and possibly IQs to the sender in some circumstances would probably the sanest way to do it.

I think the simplest generic platform you could build polls on would be some kind of templating system - and maybe forms with the display stuff is sufficient? - with a kind of encapsulated pubsub driving it, tied to a single node.

Troulbe is, I don't know what else you could build with that that's of any use.

Wait wait wait, what would you want to integrate JS or wasm for in my XMPP client?

:D

Otherwise, you need scripting. And the reason I actually quite like the notion of microapps is that a lot of innovation has occured in things like Slack Apps that looks really interesting.

Link Mauve, wasm, no JS!

jonas’, that’s already much more sensible, but… why?!

Link Mauve, Obviously it'd have to be LUA.

OH NO, NOT LUA. :p

I WOULD HAVE FLASHBACKS FROM SQL. :p

dwd, how much of that would work well in any way in XMPP, given that the wire format has nearly no control over the presentational layer since we dropped XHTML-IM?

Link Mauve, Oh, SQL-over-pubsub, new XEP coming.

jonas’, Well, yes, that's a whole other problem. We could go Slack's "blocks", mind, which is almost what we have with XEP-0141 et al.

I mean, I guess there's XEP-0336 too.

dwd, XEP-0043 you mean?

Link Mauve, Wow. "Retracted", because we don't have a state for "Burned with Fire".

:D

Wow, the DTD is fully unreadable in our dark theme.

Purple on dark grey.

did you mean: Mauve on dark grey?

Link Mauve, That's to protect your eyesight.

jonas’, I see what you did there.

:3

But anyway, yes, little somewhat-scriptable dynamic messages. Microapps, whatever. We could probably do them without any client-side scripting, or at least with something so restrictive it was a case of "If the user actuates this button send this". But it'd be nice to get something that'd handle, say, polls, or giphy, or whatever else people think up without having to have everything hard-coded into the clients.

There: https://github.com/xsf/xeps/pull/1147

dwd, buttons?!

dwd, isn’t giphy just a video player?

Link Mauve, it's also a selectino tool on the sender side

Like Movim’s thingy?

possibly, I never used movim

And you’d do that by… having some entity send you wasm code and execute it in your client? :x

Can I opt out from this future right now?

Movim says it’s using Tenor for the video search engine.

ah yes

https://tenor.com/ this one.

So the limited wasm API would still give said external entity on the network access to arbitrary HTTP requests, video decoding, widget drawing, message sending, and what more? ✏

I was proposing giving it access only to the message containing the wasm payload, plus maybe IQs to the sender address in response to user interaction.

hence, "what is that even useful for given the really low amount of presentational layer influence the wire protocol has"

Right.

Link Mauve, I'd probably avoid that for preference, and tie communications back to a fixed source endpoint and - probably - asking permission to send a specific message.

So that takes giphy and external polls out.

Link Mauve, though loading a snippet of wasm to run in your message text prompt would also be interesting

(If giphy is like tenor.com’s integration into Movim.)

Link Mauve, Don't think so? Means that the microapp provider has to mediate all communication to third parties, though.

then it should just be able to render a preview message based on your input

and by render I mean provide the message stanza

then your client can render the preview from that

(with the client stripping all things it doesn't know about)

the wasm could generate multiple variants (in the tenor case, multiple matching videos) and let you pick one of them.

then you had a wasm thing which is already quite useful to actually do things

Aaaaaaah, Movim lets those videos play sound as well! >_<

I hate it I hate it I hate it I hate it.

edhelas, ↑

It even loops, with audio.

And no way to stop it.

Great UX you have here. ^^'

jonas’, so, the wasm thing would let any external entity play sound in your client, with no way to do anything against it? :p

Link Mauve, Well, you can have a permissioning system to allow/deny audio, I suppose, but in any case, I'm beginning to wonder if it's even required to have a real scripting language, or if we can just handle UI events by passing messages and optionally replacing the entire microapp UI.

Like the abuse of 0308 we did a while ago in poezio?

I don't know about that. But given what I can guess, maybe.

 Test of <marquee/>.                    ✏

  Test of <marquee/>.                   ✏

   Test of <marquee/>.                  ✏

    Test of <marquee/>.                 ✏

     Test of <marquee/>.                ✏

      Test of <marquee/>.               ✏

       Test of <marquee/>.              ✏

        Test of <marquee/>.             ✏

         Test of <marquee/>.            ✏

          Test of <marquee/>.           ✏

           Test of <marquee/>.          ✏

            Test of <marquee/>.         ✏

             Test of <marquee/>.        ✏

              Test of <marquee/>.       ✏

               Test of <marquee/>.      ✏

                Test of <marquee/>.     ✏

                 Test of <marquee/>.    ✏

                  Test of <marquee/>.   ✏

                   Test of <marquee/>.  ✏

                    Test of <marquee/>. ✏

.                    Test of <marquee/> ✏

>.                    Test of <marquee/ ✏

/>.                    Test of <marquee ✏

e/>.                    Test of <marque ✏

ee/>.                    Test of <marqu ✏

uee/>.                    Test of <marq ✏

I love it. :D

quee/>.                    Test of <mar ✏

rquee/>.                    Test of <ma ✏

arquee/>.                    Test of <m ✏

marquee/>.                    Test of < ✏

I'm not seeing those as '308...

Oh?

I see one correction followed by a ton of subsequent messages...

Oh, perhaps the plugin didn’t get updated to the new semantics of 0308.

I’ll have a look someday, maybe.

In any case, congratulations, you've discovered something worse than spontanetously playing audio.

Link Mauve wrote "I love it" in between the corrections. Perhaps the corrections afterwards are be applied to the original marque test message, however it's not the last message anymore. Thus, last message corrections aren't accepted anymore.

lskdjf, No, I got a load of non-corrections prior to that.

hm. For me, all corrections prior to "I love it" applied fine.

:D

Ah, interop will be easy, they said...

I love marquee :)

jonas’, I mean, I hate it, but I love that it's (almost?) possible to do.

lskdjf, oh, so you have the one client doing a check for Last message correction, while other clients implement arbitrary message correction.

jonas’, I'd just like some other facilities to do more complex things like polls etc. XEPs actually built to abuse, if you like.

I mean, the XSF Memberbot could be written as a Slack App. Obviously it'd be ironic to do so, but you could easily enough, I think, write an app that people could see, discover, and vote on, and that would provide all the links etc. And I think that's a more powerful mechanism than anything we have right now.

Link Mauve: is it *one* though? I'd hope more clients aside to Conversations do _last_ message correction

mjk, Dino also accepts the last message for correction only.

Whew

Anyway, this whole conversation was a pretty traumatic rollercoaster. Javascript in stanzas? Check. Chromium in Poezio? Check. Multimedia on autoplay? Check. Trusted stanza execution environment next?

mjk, webasm in sgx in stanzas!

and smart contracts!

Webasm sounds much more benign than requiring an intel x86 cpu to poll on things

:D

12:12:13 jonas’> it's not how I (want to) use IM.

~Amen~ So say we all ✏

but with my council hat on, if members of the XMPP ecosystem want something like that, I feel obliged to guide them to non-terrible choices

(like wasm over javascript)

No matter the hat I wear, yes to that.

Link Mauve: btw, what is that Lua-related trauma you seem to have

I think the trauma might've been LUA related…

Ah, I suspected that

I see you had a Lua Uppercase Accident

I'm convinced it wasn't an accident

On a related note, there seem to be some impostor xmpp client circulating in the ecosystem, referred to as DINO. User discretion is advised

Nothing is more annoying than "signal doesn't know who sent what to whom!!!!"

They have to, to deliver it

The fact that they have a bunch of fancy mumbo jumbo that boils down to "we pinky promise not to look or remember" is neither here nor there

Looks good in marketing

Vs XMPP where jabber.de indeed has no idea who I'm communicating with on not-jabber.de

If "privacy" people can't grasp this simple concept maybe they should just communicate over SMS

But RCS is morw private!!11 Google promised not to look!

But your evil admin is all-knowing and spies on everything!

I'm sure some people misrepresent this as "signal doesn't know where a message is going", which is not true, but they do a lot to obscure where it's *coming from", maybe we should actually make something similar instead of pretending this has no value.

Sure, it's not as perfect as the HN crowd seems to think, but they're not wrong that it's a lot better than what we do (assuming that hiding that metadata is actually one of your goals)

> they do a lot to obscure where it's *coming from" TIL

I'm happy knowing which server knows what.

>vs XMPP where jabber.de indeed has no idea who I'm communicating with on not-jabber.de wut you mean xmpp server doesn't know who you're communicating with?

Sam: but in the end they are only obscuring it, there is no techincal way to prevent them associating both sender and recipient phone numbers to any given message blob

Sealed sender is probably more secure in a federated system, but oh so many things break

Ge0rG: I don't think that's true at all; the "from" payload that authenticated you is completely obscured from Signals servers, it's part of the e2e bundle

Sealed sender, that's what it was called; let me see if I can find the blog post.

It has been a few years since it came out, so I don't really remember the details well

https://signal.org/blog/sealed-sender/

They just know "some unauthenticated TCP connection uploaded a bundle, we should deliver it and the remote client can authenticate it"

Your own server doesn't strictly need to know the recipient identity either, only their server.

Obviously there are all kinds of data correlation attacks you could still do (this IP uploads bundles to this user a lot, maybe it's this other person who also uploads bundles to this user) but that's still a significant improvement

actually hiding metadata is possible in a p2p chat app. As an example one can quite easily build a chat app over Freenet where absolutely no one but the sender and receiver will know who those are; however with Freenet messages will take a few minutes to deliver so it isn't viable 🙂 IIRC in bitmessage senders are actually concealed and it works sort of but is heavy on cpu and I don't remember if messages are instant

I keep thinking about that. If my server knows who I am and the server I'm sending to, but not the user on that server, and the other server knows what server delivered it but not who it was from that would be pretty nice (although it would encourage centralization and more users on a server if you wanted that privacy so you could blend in with the crowd)

That would be some interesting XML onion.

oh yah, I'm sure it would be very ugly however it works

I guess that's more what Tor does than what Signal does. Might be possible to do vaguely what signal does too

There is also briar that works in a mobile context and p2p. And tries to hide metadata. Obviously it fits a specific use case but some stuff from the metadata and the delay tolearnt capability would be interesting.

Sam, it seems fairly clear that signal *could* track exactly which account each message came from though, right ?

"sealed sender" on XMPP would be an interesting challenge, because either you can upload bundles to any federated XMPP server, or else you've got to authenticate them to prevent (I think) various abuse cases.

And if you can authenticate them at all, you can (in principle) track identity. Well, maybe. And if you use tokens shared between clients, they could pass those tokens around and ew.

(By "maybe", I mean, you definitely could, though you might promise not to).

You could hide the sender from the receiving server with some onion like layer model. And hide the receiver from the sending server.

Yeah, you'd want something akin to Tor relays, wouldn't you?

I mean, it's all possible, just not using the model that Signal use.

And I suspect with the right data gathering of the data they do have, it'd be fairly easy to guess the senders correctly in most cases.

I think it'd be fairly easy to only tell your server the receiving server instead of full recipient JID

The problem is, this is useless for people using the same server

moparisthebest, Yes, that for sure. For basic messaging. Presence gets a bit trickier.

And also almost useless for very small servers

moparisthebest, Well, no, it doesn't, but you end up making trade-offs about who is applying ACLs and yuck. We had a big argument about this kind of thing about a decade and a half ago.

But I guess signal uses it as a "feature" so if we are just after the marketing...

Yes, as the number of users on a server tends to one, it becomes irrelevant.

moparisthebest, I'd hope we do more than marketing, yes.

Right, but that's why we don't have such a feature, it's mainly useful for marketing, not what people actually care about

And of course, this only really applies to pure consumer messaging. When you're dealing with organisations, it's a different model, and you might only want encryption and metadata hiding from the edges out.

See also: disappearing messages & time limited messages

moparisthebest, In my world (my current world, I'm departing it probably forever at the end of the month), the problem would be that any use of such a system would carry the implication that you are, indeed, worth watching very closely. (And Armour Comms does do "message burn", e2ee (by some definitions), etc).

dwd: are you ok?

wording of message seemed ominous

I mean job/industry, not life! Going back to health instead. Similar issues but without nation states trying to kill my users quite so much. :-)

dwd: With or without Erlang?

killing users with erlang?

sounds about right

dwd survived so far.

but did his users?

It's fault-tolerant. If some users are killed, this won't affect the rest of us whatsoever.

hello

hello

k

kvcx

f

d

f

df

d

i question

ask your question or stop spamming

ok sorry my mistack

*misstake

Holger, Also, users can be replaced at runtime without anyone noticing.

Which software need help. I will learning language. Now ı am learning Python.

bung: You can find software listed under https://xmpp.org/software/

emus, newsletter material "5.9 billion new XMPP users this month" https://blog.jmp.chat/b/2022-jabber-xmpp-from-sms

5.9 billion was the first estimate I found searching for number of SMS users, mix with a little bit of Matrix math, done...

Now *that's* a clickbait

> Matrix math I see what you did there

moparisthebest: can you make a PR? or add to the pad?

Put _that_ in your HN pipe and smoke it

hey if we are going to go all-in how many email users are there... https://smtp.cheogram.com/

"I have therefore determined everyone who has ever touched an electronic device is an XMPP user"

Relevant: https://xkcd.com/802/