XSF Discussion - 2022-01-26

I can create a ticket about the bad logo here: https://opencollective.com/xmpp? I have already informed a long time ago but it has been forgotten, I think, and without ticket, no following.

What's bad about it? Raster?

Neustradamus: As I recommended in my message to you yesterday, I think and still recommend you give it a bit of time before you engage in new tickets of any regard currently. You can find a decent logo in Wikipedia.

emus: It is for this that I have posted this message here.

mjk: Good logo is here: https://commons.wikimedia.org/wiki/File:XMPP_logo.svg + https://commons.wikimedia.org/wiki/File:XMPP_logo_(without_text).svg

Their canonical source is probably here: https://github.com/xsf/xmpp.org/blob/master/static/images/logos Anyway, what's _really_ horrible is the C++ pseudo-logo on the front page of xmpp.org! Here's a real one: https://github.com/isocpp/logos/blob/master/cpp_logo.svg

Shall I PR?

yesplease

mjk: it has been updated, you can look here: https://github.com/xsf/xmpp.org/blob/master/static/images/logos

The issue: https://github.com/xsf/xmpp.org/issues/608

It is good now at this place

mjk: maybe pre-emptively point to https://isocpp.org/home/terms-of-use in your PR

Guus: right (I haven't studiet the ToU yet)

ianal, but "sure, go ahead as long as you're not suggesting we're endorsing you"

How do contributions to the XSF through OpenCollective compare to the good old XSF sponsoring we also/used to have?

Guus: tell me more?

regular sponsorship is rather expensive (for individuals) but comes with perks

perks?

benefits https://xmpp.org/community/sponsorship/

Is the money earmarked differently? Should we start using OpenCollective's payment processing services (that also support recurring payments) for 'old style' sponsoring too?

Or, if there is a difference, we might want to document that publicly?

Linking to OpenCollective from https://xmpp.org/community/sponsorship/ might draw more attention to that, which I suppose is a good thing.

I've just noticed that sponsors can submit blog posts to the XSF Blog. And they're vetted by the Council for some reason.

We had that since the beginning of time, I think.

One benefit of OC-for-sponsors is that it might take away our annual manual generation of invoices, which we are bad at.

Plus, the exposure/transparency might be good.

> guus.der.kinderen escribió: > Linking to OpenCollective from https://xmpp.org/community/sponsorship/ might draw more attention to that, which I suppose is a good thing. could you PR what you have in mind?

I'm not sure if it is a good idea. I wanted to start a discussion here, first. 😊

I'm not sure that OC is the right vehicle for corproate sponsorship, but really from the corporate sponsor's side - people do seem to like invoices and suchlike.

Do we do financial reporting actually?

Doesn't OC provide those? I can imagine that they must, if.only for their accounting.

emus: our treasurer does that.

Sorry, to be clear: "I'm not sure that" is for once a genuine statement of uncertainty, not me being polite and British and saying "You're completely wrong".

guus.der.kinderen: is it public?

emus: unsure if they are published, but I don't think that they're secret.

dwd, https://docs.opencollective.com/help/expenses-and-getting-paid/submitting-expenses#invoices

It's my understanding that OC is specifically designed to be a good bridge between the corporate and FOSS worlds

Would be interested

MattJ, that link describes invoices for the payee, I think, not the payer.

> What's the difference between an individual and an organization profile? > Organizations represent a company or entity, while individual profiles represent a person. Organization profiles can have multiple team members (individual profiles) who have access to edit it and make financial contributions in its name. If a contribution or expense is for a company, it's important to use an organization profile so the correct billing information shows up on receipts and invoices. Organizations can also issue gift cards.

that suggests that invoices are supplied to payers

MattJ, Ah, nice.

but, stepping back: do we _want_ these contributions to go through the same mechanism?

I'm not seeing an immediate reason to not do this, but it's worth thinking about that for a second or two, maybe.

It's probably looking more Serious to send proper invoices without an intermediary

Just catching up, but FWIW I know a lot of organizations that do corporate sponsorship through Open Collective.

Yeah, I can't think of any reason as long as they handle decent invoincing, and they probably do that better than us.

As for intermediaries, even my plumber sends me invoivcing through Xero now.

As far as I know OC doesn't generate invoices in any meaningful sense though. That is, you can put your info in and it will make a single one geared towards expenses, and only if the other party is on OC themselves

I've been using https://app.workspace.fiverr.com/ to keep track of clients and generate recurring invoices that get automatically sent and the like, unsure if there are better options but that's been working for me (and I got it free through the freelancers union)

Or rather, you can upload your own invoice on OC and input the details, it doesn't really generate it.

>> Anyway, what's _really_ horrible is the C++ pseudo-logo on the front page of xmpp.org! >> Shall I PR? > yesplease Done! https://github.com/xsf/xmpp.org/pull/1062

ty!

Thanks mjk!

np. Wanted to do it for a long time :))

mjk: Never too late ^^

Well, CVE-2021-4034 looks like a barrel of laughs.

dwd, yep linked it in xmpp operators channel yesterday https://blog.qualys.com/vulnerabilities-threat-research/2022/01/25/pwnkit-local-privilege-escalation-vulnerability-discovered-in-polkits-pkexec-cve-2021-4034 fun since 2009 !

And wasn't it discovered in 2013 but not fixed?

ah I didn't read that ?

https://www.openwall.com/lists/oss-security/2022/01/26/7

oof

well... that's embrassing

by all means though continue writing important things in C, nothing wrong with that :D

Real programmers write in C.

like pkexec?

Real engineers don't, but that's another matter.

oh wow

programmers ^ engineers you say?

does anyone know of any use of https://xmpp.org/extensions/xep-0451.html in the wild ? cc Sam

on a related note, is there really not a generic way you can send a certificate along with a signature to prove you have the associated private key ? (outside of TLS negotiation, that is)

stop right there, before you invent something like what email, matrix or mastodon uses

DKIX?

Why would you need to anyway?

MattJ, searches aren't really fruitful, happen to know any more words? :)

Anything sent via TLS is implicitly signed by the TLS cert key, no?

What problem are you trying to solve?

Zash, to avoid dialback/mux, for piggybacking

moparisthebest, sorry, it was a name proposal, not an existing technology. Zash has been complaining about DKIM all week.

you just "hey looks like you also serve muc.yourdomain, care to send me the cert to prove it? thanks!"

or the other direction, "hey I'm already connected/authenticated to you for example.org, but I also host muc.example.org and have a few stanzas to send, here's proof"

renegotiation and ask for another client cert? good thing renegotiation has been killed with fire

how about this solution: don't

moparisthebest, I don't quite yet see the problem statement :)

wouldn't it be a lot nicer than everything else ? assuming it was simple and secure that is

demand it be covered by SAN in the already sent certificate or open another connection

jonas’, avoiding dialback/mux/extra connections

what's wrong with mux?

I mean I can agree on dialback being bad

but I don't see what's wrong with mux or even multiple TCP streams (though you may now say file descriptors, I'll raise you a "rate limiting is much easier if you only have a single stream per entity") ✏

so, what is the *problem* you're trying to solve, not the thing you're trying to make fancier :)

mux is better than dialback, that's why I was asking about implementations

I'm firmly in the "use BIDI, burn dialback, be happy" camp

but it'd be even better to *not* have to create new connections

Because really, how much does multiplexing really give you?

(Actual question that I would like to see answered with statistics and surveys)

the end game here is I'm working on a spec for XMPP-over-QUIC, and so have the opportunity to make all the good things MUST

bidi, mux, forbid dialback, it's all on the table

I don't want to *invent* a way to prove you have a cert outside of TLS, but it's kind of something I assume exists already, somewhere, and if it was nice, it could be good to re-use

oh right

I meant bidi, not MUX

just BIDI, KISS things.

or you could forbid BIDI by only allowing one-way streams for s2s connections, which is a concept QUIC supports

you can open multiple streams per connection, either way actually

moparisthebest, IIRC you need the back channel actually

for stream errors or so

yea that's what I concluded too, just stating the options

multiplexing without head-of-line blocking would be pretty nice for s2s though

could be for a client with multiple accounts on the same server as well, I guess

Is there precedent for deprecating half of a final xep? Specifically the zlib method of https://xmpp.org/extensions/xep-0138.html

moparisthebest: unlikely

awkward with MTI

So, suggestions? Deprecate whole thing and next method can re-spec it in a separate xep ?

Probably wouldn't make sense to make it a new xep now with no methods...

yeah, probably obsolete the entire thing

Anyone know how to turn 3 sentences into an informal XEP about the proper procedure for service discovery? ✏

slap some XML tags around it and send it to the editor

`echo "Start with disco#info the domain part of your JID, then disco#items and recurse, but don't get into an infinite loop." | pandoc -t tools/2xep.lua`

missing *all* the required metadata!

Tho it could just as well be a section of XEP-0030

> Version 2.5rc3 (2017-10-03) still so weird

Hi noob here, so sorry if I should RTFM or ask elsewhere first, but I didn't find much in my xmpp hist about status.im, its tech and what xsf/xmpp devs think of them?

Unrelated : https://tidelift.com/ is other possible complement to opencollective

qwestion, status.im is not XMPP and is therefore trash not worth considering :D

Not XMPP? Not on-topic. Simple as that.

After I told Neustradamus to stop highlighting people, he is doing it again. Maybe more steps are necessary now.

Sorry, different repository, but related to xmpp. got confused

emus: The error is human, I forgive you.

For information, maybe some people had not seen, I have renamed https://github.com/scram-xmpp/info/issues/1 to https://github.com/scram-sasl/info/issues/1 for a better deployment :) I am verry happy to see that SCRAM is increasingly used. The work done for many years shows success. I want to thank the developers who have been able to move this in our community.