XSF Discussion - 2018-10-16

So odd question, but does anyone know what the state of xmpphp is?

"awful"

no wait

I got confused

I have no idea.

Well, yes, it's PHP.

What I'm looking for is a way of writing a component in PHP - I'm bound to a library written in PHP, in case you wonder. Has anyone tried this recently?

dwd, maybe the movim folks?

I hear long-lived PHP processes are great!

No, edhelas seems to have a (quite reasonable) library, but it's C2S over websockets I think.

/s

Zash, It's not like I have much of a choice, unless I reverse engineer the PHP library, which is not much fun either.

dwd, no, it’s normal c2s.

The websocket part of Movim is for a custom protocol between its client-side (web) part and the PHP thing.

Oh, it talked of removing BOSH for WebSocket.

It actually removed both.

Gasp.

Just normal TCP nowadays. ✏

OK, so I could take one of the three (!) XMPP libraries I've found in PHP and hack component support into it, I suppose.

Heh, didn't we discuss s2s over BOSH once?

dwd: have a node.js web service in the backend spoken to by the PHP library :P

Zash, It has TCP/TLS support. Doesn't seem to need BOSH about.

dwd, iirc the whole nextcloud chat thing has a full fledged xmpp server written in PHP, just without federation so far

at least I know it was that way in the nearish past

That's a bizarre choice to make. Why on earth didn't they repackage an existing one?

dwd: edhelas actually merged his c2s lib into movim not so long ago. Maybe it's worth getting out again.

"This is your brain on PHP"

He was also looking into writing components for other things iirc, not sure what he's going to use

pep., You can get at it via the Composer, which is sort of PHP's package manager thing.

Maybe it's an older version then?

Not sure.

Moxl does xmpp on xmpp

Websocket in Movim is just for the frontend app to connect to the backend

dwd, pretty sure because it has to run on webhosts that only offer PHP

What does that mean

Why are there still people using PHP? And this scary webspaces that only have a PHP Interpreter?

Gah, this anti-XML, pro-JSON discrimination everywhere!

pep., j.r , you know in the not-too-distant past when a dedicated server or VPS was expensive but you could get FTP access to upload PHP files to run on some remote multi-user machine?

guess they still want to support that kind of thing, I'm assuming that's the only reason anyone ever writes PHP

https://www.moparisthebest.com/images/php_the_good_parts.png

continued popularity because popularity

I guess that's how it all started, I'm not sure what statred first though, the PHP hosting or the PHP devs :p

Doesn't >50% of the web still run wordpress?

moparisthebest: yes I also used them, but today PHP is not the best anymore

neither is windows or mac or skype or signal or, well I could literally go on forever

j.r, has it ever been

It's easy to get started after learning HTML basics

still it exists :'(

> j.r, has it ever been No not really in my opinon

> It's easy to get started after learning HTML basics Also work with NodeJS or also Java Enterprise or whatever

In case anyone is interested, on HN someone was complaining about this page being out of date, so I started updating it (added OMEMO, removed a bunch of old mechanisms that no one cares about, added clear recommendations):

https://conversations.im/omemo/audit.pdf

err, oops: https://wiki.xmpp.org/web/XMPP_E2E_Security

words of praise

Please feel free to jump in; the table also needs updating but I am struggling with this wiki format

And there is probably more important stuff I don't know about

pandoc, the best thing ever, can generate mediawiki format ;)

SamWhited, for OTR I would add the transport use-case in recommentations

As in, you don't need protocol knowledge to use it, shove that into <body/> (:() and you're done

Does anyone care about transports enough to make that useful information? (serious question, I have no idea; I know the Matrix people like to advertise them, but I'm not sure how widely they're developed or used)

I am not an e2ee user, but I know a few users still using OTR because of that

"a few users" probably doesn't mean we should keep recommending OTR though, personally I want it to die in a fire though, so maybe I'm just projecting that onto what I think the recommendations should be

We all have our own bubble right :)

Actually, SCIMP probably doesn't need to be on there either. Is there a single implementation that's not whatever their client is?

I never heard of SCIMP before

yah, me neither until I saw this page

Also what about MLS? Do we want to "pre-list" it in there?

Is that the RFC thing?

yeah

SCIMP

Internet Draft right now.

I wouldn't link an untried RFC with no implementations personally, seems like it's just muddying the waters.

Also OX

That should probably be listed alongside OMEMO

I guess we could put it on their as "future work, recommendation: watch" or something

Though I don't have actual knowledge on that either

SamWhited, I think MLS will take over everything, eventually. I was working on a XEP for it, but it's a little too much in flux right now.

I'll believe it when I see it

I'm worried about having yet another complicated protocol and generally don't trust the IETF with this sort of thing, but also it seems like something that should be done there and not by us so we'll see I guess

But I still haven't done anything but glance through it, so grain of salt I guess

You don't trust the IETF? In what way?

I mean, if you mean, "They're really slow and might never get it done" I can somewhat sympathise, but the crypto and protocol I'm willing to trust.

I just generally think they overengineer everything and pick use cases that are way too general

https://tools.ietf.org/html/rfc6121#section-13.2 hmmmm

Well, in this case, the use-case is handling groups of participants with e2ee. Seems OK to me.

But I'd also rather see them developing something than every random company going it solo

A lot of CPIM and so on was actually our fault. Or SIP's, depending on how you look at it. Either way, the industry was split and couldn't really pick a standard. The result has been no standard.

Right, now we have OMEMO which is starting to gain adoption and are developing another standard. Things haven't changed much.

Except OMEMO is in a weird state too

It's true.

at the moment, whether anyone wants to accept it or not, it's whatever Conversations decides to implement will win

Conversations is the new Internet Explorer \o/

Zash, that's harsh, but I see where you want to go

or Chrome

or Netscape

I suppose Pidgin might be the IE

But I don't think that's entirely true; Conversations may drive a lot of development, but as long as they do it in the open with community involvement it's probably okay

> I suppose Pidgin might be the IE +1

Right. The current spec doesn't even reference the Signal spec needed to implement.

I agree OMEMO has problems, but they seem fixable. Seems like we're throwing the baby out with the bathwater if we start over.

Then again, maybe it's better enough to justify that, I just don't know.

Well, OMEMO really doesn't scale well for chatrooms, whereas MLS does.

So depends if you want >10K scaling in pubsub and chatrooms, I suppose.

Yah, maybe that's enough of a reason; I'm just scared of throwing out all the progress we've made again

But that is a pretty good one if it can really scale that well

I must make sure my sketch-design for offline/non-escrow encrypted archives still works after the last major changes, though. I think it does.

I guess that's only a corporate use-case, >10K people in a single chatroom, because I've never seen/heard of that in the wild

Or maybe we're planning for when XMPP becomes great again

pep., Sure, but OMEMO won't really scale well enough for, say, xsf@ or jdev@.

Back to the wiki: is OX XEP-0374? It doesn't appear to have been worked on in a while, is it worth including? Are there many implementations?

SamWhited, Smack does it I think. Not sure how many clients use it.

SamWhited, Most use the OMEMO/Signal plugin for that, even when they're not GPL clients, which is hella-awks.

SamWhited, that's the one

Thanks; doesn't seem worth including if nothing uses it

The good thing compared to OMEMO is that container

(nothing end user visible, I mean; it's neat that Smack does it)

SamWhited, I'd actually appreciate all the historic and aborted attempts being documented.

That includes more than just <body/>

pep., Right, but eSessions had that a decade ago.

dwd, sure

I was also wondering why OMEMO didn't use it

pep., And, I think, did it in such a way it was reusable.

(nice features, widely used) pick one

Zash, I'm not convinced OX is all about nice features, mind.

dwd, I'm not arguing for OX per se

(I'm not arguing at all)

Is this the right room for an argument?

No idea, but we don't have to figure this out if it isn't one :)

https://proxy.duckduckgo.com/iu/?u=http%3A%2F%2Fjpegy.com%2Fimages%2Fuploads%2F2015%2F07%2FNot-take-only-throw.jpg&f=1

no argument, only spec .. or something

Right, but actually, it's "No argument, only implementation in a popular client".

No agreement, only implement!

Partially filled in OMEMO in the table; didn't do the crypto properties because I couldn't remember off the top of my head

If someone else has the confidence to finish it I'd appreciate it

I guess I can remove the column "Online chats" from that able too… unless that means something that I don't understand? Isn't that just the same as 1:1 and groupchat columns? Obviously the e2e mechanisms all work with "chats"…

*that table

Or the "encryption" column too for that matter; I know it's a property that not all cryptosystems provide, but given that this is a page about e2e encryption…

Someone who thinks xep393 is markdown. Do we burn it with fire now?

I think everyone just calls everything that looks like Slack/Watsapp formatting "markdown" even if it's not

It's very confusing

I fear this confusion will eventually lead someone to use a generic markdown library (with html passthrough enabled by default) and then the sky falls.

If they did that it wouldn't be compatible at all and their formatting wouldn't be the same, so I suspect they'd nontice

I suppose it's possible they wouldn't notice, at least some of the styles are the same, but I suspect someone would want bold or italic or whichever isn't the same and notice

Oh boy, positive and optimistic words towards OMEMOs future, hell yeah! In a few weeks I'll finally get my lib to a stable state, then I'll start pushing towards this "better future".