XSF Discussion - 2019-04-29

Subscribe to this youtube channel: https://www.youtube.com/channel/UCJMr4LzZvisWnfK1Ilk2RnQ?view_as=subscriber

Hi guys. What do you think if I make a PR to jingle-s5b spec according to my remarks on wiki. It will also require advance its ns

Basically I'm going to introduce candidate-complete event with meaning no more local candidates (trickles) left.

This will allow significally simplify negotiation with trickles. And the advice to put as many as possible candidates to session-initiate won't be that relevant anymore

rion, trickles?

The candidates sent with transport-info

Additional candidates

rion, Is that term somewhere defined? I just greped the XEPs repo for it

Basically it's related to ICE

rion, I would suggest posting at least a strawman of your proposed changes to the standards@ mailing list, then wait for feedback and eventually create a PR

given that this is jingle, I don’t expect any feedback on the list :(

I'd also CC the authors of the xep (I suppose we are talking about xep260?), but don't expect much feedback

what jonas’ said, but at leat it is archived and documented somewhere…

I also would not be surprised if a namespace bump experiences some resistance. But my impression of is jingle possibly deserves an overhaul…

There's a jingle feature arriving on dino, I'm sure they would have a look. Also there's a few clients implementing it.

That's why I want to change it. I'm implementing it in Psi and found many unclear parts. But this current state of jingle-s5b forced me to implement some overcomplecated logic. I don't like it at all.

ideally we would be able to bundle all changes, and not namespace bump on every single one. Smack also has some ongoing jingle work, but I don't expect it to be finished before the end of the year

if only we had a proper staging area for updates to Draft XEPs

and a staging namespace

possibly that, too

urn:xmpp:jingle:5-(next|dev|staging|…)

Semver-ns

urn:xmpp:jingle:5.1

+1 for semver

they are already semver

if the changes are non-breaking, you don’t need to bump the namespace

so you don’t need the minor version number in the NS

yep, I don't also don't see a reason to use something like semver for xmpp namespaces

jonas’: sure, I could bump major at every single change and I would also be semver compliant

But that's not really the idea

pep., that’s not at all what I was saying

Ok I'll post on ml tomorrow

jonas’: I was saying there's different readings of that spec (as there is for every spec)

Btw, I can split my proposal in two parts. First is not breaking. It just says to not send candidate-error/used until all local and remote candidates are acknowledged. And this also suppose if candidate-error/used was send by remote and we send a new candidate to remote afterwards, the remote state machine has to invalidated. It's not a requirement though. Another part is the candidate-complete event

Decided to send my thoughts now. It's on ml =)

pdurbin, have I conviced you? Become a member :). If you are a member on the XSF conf you have dinner for free :D. Plus Cap! :-o

<blink>FREE DINNER</blink>

Now I want to be a member too!

It's only free if you live in Brussels.

😭

Heh.

That said, https://wiki.xmpp.org/web/Membership_Applications_Q2_2019

> Applications will be accepted until end of business May 12th, 2019

XD

> It's only free if you live in Brussels. Not true >:(

s/Brussels/that tiny village where the restaurant is/ ? :)

Zash yes <blink>TINY VILLAGE</blink> ✏

Before I join, I'm trying to figure out if I can have a user experience I'm happy with. The big thing is history. Slack excels at this. I used Conversations over the weekend on Android and fired up a second client today, Adium on a Mac. From Adium I don't have access to my one-to-one history that happened on Conversations like I would on Slack. Is there a solution for this? Is this the fault of my XMPP provider (FSF)? Can they enable history or something?

:D pdurbin

What you are asking for is called MAM.

pdurbin: I think the problem is that Adium is outdated.

But MAM is useless with later joined OMEMO devices

With Mac you are unfortunately in a not so nice situation. You should ask for another client.

j.r I think he asks for MAM in this MUC here thus no omemo keys ...

Zash, what was again the best client under MacOS? I forgot it.

I don't run MacOS, so I'm no authority on this.

Monal is more actively developed at least, so give that a shot?

Hi

Hey

https://xmpp.org/software/clients.html had more MacOS options listed than I expected

Sure, I can try Monal tomorrow. Thanks!

Watch this really cool video, also subscribe to the channel! https://www.youtube.com/watch?v=sVzBhGE3w40

Watch this really cool video, also subscribe to the channel! https://www.youtube.com/watch?v=sVzBhGE3w40