jdev - 2023-08-26

“19:50:31 opal> profanity implements omemo and its one of the tui clients that does it reasonably well”, did you have any issue with poezio’s implementation of it?

Trung too I guess, ↑

>Los sitios web acreditan su identidad mediante certificados, los cuales son válidos durante un plazo determinado. El certificado de dev.poez.io caducó el 2023/8/20. >Código de error: SEC_ERROR_EXPIRED_CERTIFICATE lol thats their current status?

cant even see their bug list

oh theyre using this https://codeberg.org/poezio/poezio/issues

>python thats why i didnt touch it

Is there somewhere a guide on what jingle xeps are required and how they all fit together? I read the 2023 conformance and says a whole lot of xeps but not how they fit together. From what I understand Its: 166-Jingle that does XEP-0353: Jingle Message Initiation that does XEP-0167: Jingle RTP Sessions with https://xmpp.org/extensions/xep-0177.html

or is RTP optional I can do only Jingle natively? Because reading the xeps it seems like RTP is just an alternative way of doing the initial handshake

which 353 should cover according to the compliance guide 2023

MSavoritias (fae,ve), RTP is basically a way to encasulate whichever codec into an UDP socket.

You might want TCP instead for XMPP.

ah so if i dont want UDP then i dont want RTP right?

and I just use 353 directly and a jingle transport

353 for the call setup instead of RTP that is

(I want to use cadet probably with jingle instead of tcp/udp)

MSavoritias (fae,ve): jingle is a framework for out of band data transfer. Are you trying to do calls? File transfer? Multiplayer game?

MSavoritias (fae,ve), the easiest transport to get started, and the most compatible one, will be XEP-0261.

> MSavoritias (fae,ve): jingle is a framework for out of band data transfer. Are you trying to do calls? File transfer? Multiplayer game? I was thinking of calls and file transfers with it. Calls because its the only one in xmpp, and file transfer because its either this or http or inline binary to my understanding

so I might as well do file transfer with this too

MSavoritias (fae,ve), if you want to do calls you want RTP, if you want file transfers you want XEP-0234.

So for calls do you want to be compatible with certain existing apps? Or trying something new?

Link Mauve, yeah th 234 was what i was looking for file transfer. but didnt you say RTP is for UDP basically?

> So for calls do you want to be compatible with certain existing apps? Or trying something new? I am looking into using https://xmpp.org/extensions/xep-0247.html > Jingle XML Streams for p2p with a trasport over the cadet protocol instead of udp/tcp

Calls are (almost) always UDP+RTP yes

with a trasport over the cadet protocol instead of udp/tcp*

+ DTLS-SRTP for the encryption.

so i was wondering if rtp is required for jingle calls at that point

If you want a new transport you probably want a new xep you make up for that

and how it all fits together

MSavoritias (fae,ve), for calls you don’t want TCP semantics, you want packets to drop so new ones can get there quicker.

yeah i know. so then i am using jingle and 353 probably

Which one is 353?

https://xmpp.org/extensions/xep-0353.html

Sorry, I meant title

> MSavoritias (fae,ve), for calls you don’t want TCP semantics, you want packets to drop so new ones can get there quicker. Cadet has optional reliability per channel so probably i can disable the reliability for jingle

> Jingle Message Initiation

^

> This specification provides a way for the initiator of a Jingle session to propose sending an invitation in an XMPP message stanza, thus taking advantage of message delivery semantics instead of sending IQ stanzas to all of the responder's online resources or choosing a particular online resource.

Ah yeah. So jingle core + jmi + new xep for cadet stream negotiating

yeah thats my thinking

good i got it correct ^^

You might want an rtp thing inside of cadet instead of inside of UDP, but will depend what your stack prefers

why?

Benefit of RTP is it has the envelopes for codec details, DTMF, etc stuff already

i was thinking of doing this for encryption: > XEP-0396: Jingle Encrypted Transports - OMEMO

> Benefit of RTP is it has the envelopes for codec details, DTMF, etc stuff already ah. hmm. yeah i will see

Is cadet not encrypted already?

yeah it is. so you also may argue that omemo is overkill in that case

i mean tls is useless

The benefit of RTP is also that literally everything else is already supporting it.

If you want to interoperate with any calling thing, you can be sure it will use RTP.

Right

well my client will be gnunet only

so in that sense idk how much i will need that compatibility anyway

at least thats my thinking

You don’t want to be able to allow e.g. a recorder application? Or a gateway with the clear net?

Or with SIP or such.

plus you'd have to rewrite webrtc etc

They'll need to anyway

WebRTC has transport baked in

great. and i was thinking about it

anyway..

I dont plan to add gateway support no. why would i want SIP?

But there may be some libraries or gateways that are nice to use with RTP still. I'm not saying you have to use RTP but I'd suggest at least considering it unless it makes things harder for some reason

yeah it can be added as an extension probably at some point

MSavoritias (fae,ve), to call people who are using the PSTN for instance.

its not like its set in stone

my advice is even if you want to rewrite the world don't try to do it all at once, otherwise you'll probably never accomplish anything, much better to use existing components and rewrite bits at a time

im trying to lessen the amount of stuff i need to write yeah. both by lessening requirments and by reusing stuff

like the RDF library or i have an xml parser already in guile

Gstreamer also has working RTP elements which you will likely want to use.

> MSavoritias (fae,ve), to call people who are using the PSTN for instance. im still confused. Why would i want: > Public switched telephone network

Yeah, so in short term the question is if you have a library that does RTP well then use it, otherwise maybe just stuff opus raw and decide later 🤷‍♂️

is it because of calling phones?

Also for camera access, for video and audio encoding and decoding, etc.

Oh yeah, guile probably has gstreamer stuff then RTP becomes a win I bet

adjusting quality based on link speed etc etc

yeah gstreamer is my other plan

since it uses glib and i have already bindings with guile

it could be easyish to use it

its probably not that tied to http like webrtc too so i can just get the codecs and rtp and abstract it over cadet

WebRTC is pure RTP, it doesn’t do any HTTP thing.

be really careful using an off-the-shelf XML parser for XMPP, that's been the source of countless vulns when not configured to ignore the 999 bad parts of XML

999 laughs~

yea you actually do want webrtc, it's just a sane default set of RTP things

yeah i am aware

i was talking about webrtc the package

google libwebrtc is indeed disgusting lol

which i would like to avoid. hence why i was thinking of gstreamer

which afaik gstreamer is very good

Does it do any HTTP?

yea that's what dino did, it's also why dino is the least compatible webrtc client sadly

my library? no

libwebrtc isn't tied to http either. Or do any http thing. But it's annoying to build

there is no http support

MSavoritias (fae,ve), Google’s.

ah

its the building process for me and all that stuff. it seems like a disaster

compared to gstreamer that is

moparisthebest, what are the issues with compatibility?

moparisthebest: I think we've squeezed out most of the edges in dino now

plus monoculture and all that

I don’t think I’ve ever encountered them, but I seldom call people and pretty much only Conversations.

Lots of options for webrtc stack, but in guile I expect gstreamer is easiest

it's just not reliable at all, rings but won't answer, answers but won't connect audio etc etc I know singpolyma has been working on them a ton so maybe they are all better now

> Lots of options for webrtc stack, but in guile I expect gstreamer is easiest yeah pretty much

moparisthebest, oh I never experienced those.

I should try it more.

xmpp calls is how I do 99% of my communication these days, 100% of communication with my family, so I use it a lot, they are all on either conversations or cheogram

the other 1% are still xmpp calls on my end, but through jmp.chat to people who still use phone numbers

Ah, I use text way more than calls.

Eww calls

well me too but still do calls :)

There is a single person I enjoy doing calls with, because it’s more like being in the same room doing different things and being able to talk with each other whenever we feel like it.

And not like a call where you are expected to give your entire attention to the other person.

Yeah, that's how I use mumble

yeah mumble is nice.

voice rooms in xmpp though when ;)

I got like a third of the way there then stuff came up

Eventually

mumble over XMPP when?

Zash: you mean a gateway? Or just same UX?

Half-joking, but probably more towards the gateway thing.

Yeah, it's possible I think. Basically use a mumble server as the SFU for an xmpp voice room

Not sure what the protocols look like, maybe they could be squeezed thorugh Jingle?

There is a mumble WebRTC gateway already

So needs some adaptation for jingle

Their protocol is basically sending raw opus packets to the server over TCP.

yea there's https://github.com/johni0702/mumble-web & https://github.com/johni0702/mumble-web-proxy for instance

what xep do we use to put the omemo keys on the server? is it just pep or do we do XEP-0222: Persistent Storage of Public Data via PubSub

MSavoritias (fae,ve), yes

0222 is just suggestions for pep settings. So it's "just pep" but it may use those settings, they're probably sensible for this case

makes sense. another thing to add to compliance then next year

Except I'm not sure if base PEP supports 222/223

it only mentions 0223

https://xmpp.org/extensions/xep-0163.html#defaults > A PEP service MUST: > ... > - Support the "open", "roster", and "whitelist" access models.

Hm, Prosodys older implementation didn't do that

Prosodys *current* doesn't either :(

(missing the "roster" access model)

Really? Prosody doesn't have roster model yet?

No

While I can emulate it with whitelist, that one and also one for certain roster groups would be super nice

Definitely a nice to have, but nothing so far really requires it and there hasn't been that much demand or interest in it

I assumed gajim's private profile stuff used roster

Maybe in the future if ~roster groups~ circles makes a return!

Private whatnow?

Gajim you can set profile (vcard4/avatar) to private iirc ✏

I thought it was a toggle between "open" and "presence"

"presence" and "roster" are confusingly named

Oh. Maybe I'm confusing roster and presence

"roster" is about roster _groups_

I mean, it'd be nice to restrict your profile to only especially trusted family/friends or so, but that's easier and probably better done with a separate account

Oh, roster is specifically the groups stuff. Ok. Yes, very nice to have but slightly less surprising that it's missing ✏

In general I want to avoid ever having more than one jid per persona

(except for my 6000 test JIDs of course...)

> Treat the account owner's bare JID (<localpart@domain.tld> or <domain.tld>) as a collection node (i.e., as the root collection node for the account's virtual pubsub service). Collection node?!

https://xmpp.org/extensions/xep-0248.html

This maybe?

XEP-0248: PubSub Collection Nodes

I know what it is, I'm wondering why it's mentioned in PEP

Collection Nodes were removed from XEP-0060 at some point in the distant past

You can still find traces of it, wondering if this is one such trace

Wow, even 0060 can have things removed? I thought that's where we put everything

So goes the legend