XSF Discussion - 2020-04-15

govanify =zosch@jabber.ru?

Zash =zosch@jabber.ru

?

I started out as a 14 year old lesbian 10 years ago marginalized by society and bullied in school, the daughter of two diplomats i was well travelled and read at an early age and taught by some of the best minds in the world in the intricacies of bank account cashouts.*fraud boss of international crime see PGP for details look on masterlist ahmia.fi > masterlist ExpectUs Fraud Fullz Cashout Crime Boss Hansa WSM apollon nightmare

none of this was a bot i type fast and i cashout fast

🙂

😉

tftp 10.1.1.1

lol

--

'

select * from CASH where 'my bank account ' == > 1,000,000,000,000

🙂

select * from big_titty_bitches

select * from lesbians who love buttsex just like me

Are there any working implementations of Jingle?

rion: ^^

tom: yes. What specifically are you looking for?

Videocalls

On linux

Without a web browser

https://upload.nuegia.net/adde0e10-bf17-487b-be96-afb7fc6ec6dc/qsbti5vpk9841.jpg

tom: https://desktop.jitsi.org

Hi, is anyone has a book for xmpp starters ?

http://shop.oreilly.com/product/9780596521271.do is still the best option, I believe (author).

⭐ ⭐ ⭐ "Must Read" The Daily XMPP - 2009

Kev, not time for a n++th edition yet? :)

Zash: There are definitely interesting new things to say, although it feels like we're on the cusp of there being pretty much a whole new story about how one works with XMPP, and doing anything before that would be premature (even if we and O'Reilly were motivated to do another edition - I hate writing ;)).

Thank you all, I hope if you have any advice in this technology i'm new here in this field and I hope to make good things with it

I remember http://shop.oreilly.com/product/9780470540718.do being pretty good, but not sure how well it has aged, with how fast the web has moved

Mr.eslamo maybe https://xmpp.org/about/ could help

MattJ: Modern XMPP - The Book? 😝️

When "Modern XMPP" exists, I think that would be sensible

if you want to understand the basics, I think the best is to open a XMPP console and start to play with it :)

flow, you wrote on the list that you would review MAM (thanks for the diffs btw) - do you plan to give any feedback?

otherwise I plan to request merging soon after addressing the existing feedback

Zash: Thank you, I will purchase this book and I'll start using it because I have ZERO knowledge about this technology 🙂

> if you want to understand the basics, I think the best is to open a XMPP console and start to play with it :) And read the rfc

People always under estimate rfcs

Zash: I think the issue with that one is that stanza.io is mostly unmaintaned now, isn't it?

Now that Jack The Moffit doesn't XMPP anymore.

Wasn't it using Strophe.js?

That's still around afaik

I think you mean strophe.js? And that's maintained

Sorry, yes, I'm getting names muddles.

I could check if I just reached like an inch further up my bookshelf

MattJ, I plan(ed) to. But I think you can take the silence as "mostly lack of disagreement" on the proposed changes ✏

Yup, Strophe.js and jQuery.

> Re: [Standards] OMEMO:2 Spec Sprint I read "OAuth2 Spec Sprint". :/

Not yet

Daniel, XEP-0333 in MUC: https://github.com/xsf/xeps/pull/927

and whoever was in the conversation about 333 status code in MUC: https://github.com/xsf/xeps/pull/926

(333 is purely a confusing coincidence)

It says status code 307?

307 is what has been removed (from the examples)

Nice ellipsis Github, thanks

The examples were suggesting that a server would send 307 + 333 together

But it only makes sense to send one or the other

Unless you want legacy clients to make it look like people keep getting kicked from the room

I wanted that :>

I assumed it would be pep. ;)

Saying things on me while I'm away!!

I'll have to look into poezio code again, not sure how I did that

MattJ: when parsing a marker do I have to check both - if the ID matches stanza-id and normal. Or do I switch over depending on the availability of the stanza id namesapce on the room

depending in the stanza-id feature availability, i'd say

as you can only trust <stanza-id/> it a 'by' value of the MUC's bare JID, if that JID announces the stanza-id feature, and hence announces that the MUC will prevent stanza-id spoofing

Yes I agree

The same goes for adding it imho

Currently the text says if there is a stanza id

I think that should be changed to read if the feature is announced

Then you can follow the same rule for sending and receiving

Sounds sensible

> Therefore, if a MUC announces support for &xep0359; and a &lt;stanza-id&gt; element is present within a markable stanza with a 'by' attribute matching the MUC's bare JID, this is the id that MUST be used when returning chat marker updates.

?

Daniel, not sure if I understand your point about sending vs. receiving (do you mean sending == adding <markable>, receiving == responding with <received/>?)

MattJ: no I mean the decision on whether or not to use the stanza id (over the message ID) is the same on all sides

Hmm, right

The one who sends out the displayed and the one who receives it

Should usage within a MUC that doesn't advertise stanza-id be discouraged?

Maybe

I think reactions will do that

Also what if a client adds <markable> to a message that the MUC doesn't archive?

I'd be OK with it not working in those cases

<p>Therefore, if a MUC announces support for &xep0359; then clients MUST always use the MUC-assigned id for Chat Markers. The id will be contained in a &lt;stanza-id&gt; element inserted into the stanza with a 'by' attribute matching the MUC's own JID.</p>

<p>As per XEP-0359 security considerations, clients MUST only trust a &lt;stanza-id&gt; element with a 'by' attribute that matches the MUC's own JID, and MUST ignore any such element in MUCs that do not announce XEP-0359 support.</p>

That sounds reasonable

Updated the PR

Daniel> I think that should be changed to read if the feature is announced that would be redundant to what the stanza-id xep already says

Not really

I am usually against XEPs repeating what other XEPs already say, but I see that there could be exceptions to that rule

MattJ, how not really?

Of the two paragraphs above, the first one applies to Markers only ("if the feature is present, the behaviour of your Markers implementation changes like this:")

The second paragraph is duplicating what XEP-0359 says, but I chose to do that as it's calling out security stuff

There is a high chance that someone implementing Markers would accidentally overlook that

yep, hence I said that there could be exceptions to that rule

but those really should be scarse

MattJ, "MUST only trust" does not sound right, you could trust other <stanza-id/>'s too

Alternative suggestions welcome, I changed that several times

that is nitpicking, but I think that paragraph could become a blueprint for other <stanza-id/> using XEPs

and we usually write empty elements, so instead of <stanza-id> XEPs typically use <stanza-id/>

MattJ: As per XEP-0359 security considerations, clients MUST only trust a <stanza-id/> element with a 'by' attribute that matches the MUC's own JID, if the MUC's own JID announces XEP-0359 support.

I had something like that, but didn't want it to sound like "If the MUC's JID announces support, you most only trust 'by' with the MUC's JID"

i.e. if the MUC doesn't announce support, trust any

hmm, maybe additionally specify that the stanza-id shouldn't be trusted if the support is not annouced?

"If XEP-0359 support is not annoucned, then <stanza-id/> elements with a 'by' attribute that matches the MUC's own JID should be considered spoofed and be ignored" ✏

something like that

Yep, that sounds better

How's this?

<p>As per XEP-0359 security considerations, if XEP-0359 support is not announced then &lt;stanza-id/&gt; elements with a 'by' attribute that matches the MUC's own JID should be considered spoofed and MUST be ignored.</p>

s/matches/match/

like it

ahh, hmm, maybe specifiy where the xep359 support is announced?

just to make it bullet proof

"is not annoucned on the MUC room's bare JID"

i'd probably s/MUC's own JID/MUC room's JID/, but that could just be me

Pushed

Hey all

any one online here ?

Anything other than Jitsi that can do videocalls?

There's a bunch actually. Telepathy based things, Pidgin(‽), Gajim, a few others. Atalk I heard.

I had a phone running Linux making voice/video calls over XMPP 10 years ago. ✏

Gajim not on Windows right?

Movim also

Gajim I don't think so no. Audio might work though