XSF Discussion - 2022-10-28

goffi: is there anything more recent on the xmpp - ap gateway then this blog post from over a year ago? https://www.goffi.org/b/libervia-progress-note-2021-w38--flt

Daniel: https://mastodon.social/@Goffi/109041720745109969

Daniel: I'm about to write a blog post soon about it, I hadn't the time 'cause I had to rush due to grant deadline.

Daniel: basically everything is done, but alpha quality, and I'll stabilize during the next few months.

Early adopters can try with the repos, and I hope to do a release by the end of year.

Daniel: You can also check the documentation at https://salut-a-toi.org/__b/doc/backend/components.html#libervia-components

OK maybe next year for the release, end of year is quite close now, and there is a lot to stabilize.

> Daniel: You can also check the documentation at https://salut-a-toi.org/__b/doc/backend/components.html#libervia-components Thanks. The part on the ap gateway is very interesting

Essentially what I was looking for (how to set it up and how one would develop clients for it)

It also conveys the complexity of mapping the two protocols.

yes mapping the two protocols has had its share of difficulties.

Daniel: are you still planning to implement XEP-0277 into Conversations at some point? It remember you saying that a while ago.

I remember*

yes very much. I essentially want to replicate WhatsApp status / instagram stories or what ever you want to call it; and with a bridge into AP people would immediately have accounts they could follow

but implementation wise it makes much more sense to do this after Conversations 3.0

cool :)

That CAST draft protocol I shared here the other day, this is an alternative Matrix-based proposal: https://turt2live.github.io/ietf-mimi-matrix-transport/draft-ralston-mimi-matrix-transport.html

Do we need our own version?

I'm not sure I understand what they are doing with it. It feels very generic/high-level

It's in the context of the messaging interop group I've discussed here before (and on-list). Basically they're looking to recommend a set of specs for (at least) the large company's the EU has defined as "gatekeepers", so each gatekeeper doesn't end up just devising their own protocols that everyone else has to use to interop with them

Since the EU didn't actually define a common standard that they must implement, there is a perceived opportunity to get everyone on the same page regarding messaging

(cisco seems to be using it as an opportunity to try to create yet another application layer messaging protocol layered on mls, which is depressing given both xmpp and matrix could layer over mls fine).

I think it's probably right, as long as the cost to them of implementing something standard is significantly lower than coming up with their own thing and documenting it, otherwise the cynic in me says it's a lost cause.

Does the XSF have money to put into it? Or should it not care?

Kev, basically opening up part of their API and saying "good luck with that"? ✏

Kev, I think a lot of people at the last meeting expressed the same concern, that it's a lost cause. But I think enough people think it's at least worth a(nother) try.

> pep.: > Does the XSF have money to put into it? Or should it not care? Isnt xmpp already a standard? So theoretically it doesnt need to do anything EU or the vendors can just pick it up. Matrix(Element) seems to just want to catch up to it in that sense. So i dont see what xmpp would be missing except money to "market" itself

> , I think a lot of people at the last meeting expressed the same concern, that it's a lost cause. But I think enough people think it's at least worth a(nother) try. I don't think I said I thought it was a lost cause. Just that the offering has to be enticing vs doing the bare minimum.

MSavoritias (fae,ve), that would be a good start

I think also the fact that a lot of big messengers either already are or were in the past xmpp, makes it easier already to use xmpp as the gateway

> Isnt xmpp already a standard? Yes, but 6121 on its own doesn't cover all the areas that need to be exposed, such as e2e.

Are people really thinking e2ee can be exposed?

Ok. How about then the xsf can fund an editor to compile the minimmum amount of xeps to that vendors have to implement?

> replicate WhatsApp status Daniel: is that more sophisticated than <presence status="... ? (I hope very naive questions are OK here, let me know if it's not)

With mls/omemo as an optional future thing

> I hope very naive questions are OK here, let me know if it's not Please do. It's great if it's not just XMPP nerds talking crypted together

nicomuc: WhatsApp Status is a picture that'll be shown for 24h AFAIK.

I think such a document would be a great start. Especially by the xsf. And the effort would be smaller than what matrix is doing.

nicomuc: yes it's rich content and there can be multiple of them

oh OK mdosch, thanks, it's not a text status then

Its one to x pictures, in an automatic slideshow, and WhatsApp has the tools to easily write a bit of text on them before uploading.

And videos can be part of the slideshow too, to mixture of text, videos, pictures that scroll through

MattJ: I would really like to support here, but I don't know how ✏

goffi, https://salut-a-toi.org/__b/doc/backend/components.html#messages-delivery the Note forgets to mention protocol-agnostic e2ee mechanisms like OTR. Not that I'm especially fond of it but it's still one of the use-cases. I'm sure there are JS implementations of OTR, it wouldn't be too hard to bolt it on Mastodon or other AP web thingy

pep.: well, while probably doable technically, I doubt that it's a use case: if one wants privacy nowadays, there are plenty or more or less good options (including XMPP), and ActivityPub is not one of them (for now a least). I don't see the point of using OTR with AP when there are many better options. This was making sense at the time when MSN Messenger was the leading chat service, but now we have several options to do more or less good e2ee. If one day we see an AP implementation with OTR available for direct messages, then OK I can specify it in the note, but at the moment it would only be confusing for no reason.

doesn't OTR require both parties to be online at the same time and use the same devices? seems like it wouldn't work for activitypub

Who knows what otr4 can do

does it actually exist yet ?

At least the name on github, doesn't look particularly active...

Last I looked it was the half-life 3 of encryption protocols (can't say Duke nukem forever anymore)

> moparisthebest: > 2022-10-28 05:02 (GMT+02:00) > Last I looked it was the half-life 3 of encryption protocols (can't say Duke nukem forever anymore) 😂😂😂😂

OTR sounds like a handwriting recognition system

projjalm: that's OCR

yup, I know, that's why it "sounds like" xD

> pep.: well, while probably doable technically, ... I don't see the point of using OTR with AP when there are many better options..... it would only be confusing for no reason. +1

ping

jonas’: ᵷuᴉd

delivery failed

try FedEx?

the federated extensible... wait a minute

Federated chat starter pack: > Server-to-server connection failed: connection-timeout

federated XSF chat that'd work when XSF is down... it's a fun idea :)

Sounds distributed, not federated ;)

Yes, let's sink countless hours into that to prevent the <1h of downtime since... can't remember when we last had any noteworthy downtime on this server (I guess when we migrated it from the old server)

Honestly it's amazing s2s links work so well

It's honest by not working when it's down

In last job the network guys wouldn't stop severing TCP connections on our LAN and defended this with "you can't expect TCP connections to stay up over the internet", so it was fun to show them the netstat on the server running in my closet at home (residential connection) with 40+ day old TCP connections to Germany

Not that they fixed anything of course...