XSF Discussion - 2020-05-13

Also of interest, the Eclipse Foundation has decided to move from Canada to Belgium: https://newsroom.eclipse.org/news/announcements/open-source-software-leader-eclipse-foundation-announces-transition-europe-part

pep. That could be a very good opportunity. What can we do to secure funding? I'm guessing we need to define explicit ways to make use of the funds?

Are we a 501c3 again?

I don't think I've ever seen that anywhere on the website

https://xmpp.org/about/xmpp-standards-foundation.html ought to have a link to the bylaws somewhere

At first that kinda look like encouraging solutionism (again). But then there are things like “Research and documentation on: Censorship / use of surveillance” :p

pep., https://xmpp.org/docs/XSF-Tax-Exempt-Ruling-2007.pdf

ok

The page I linked should also mention the form of corporation

Zash: https://xmpp.org/about/xsf/bylaws.html doesn't say either

(I just know the URL, don't remember where I found it)

https://xmpp.org/about/xmpp-standards-foundation.html#council > as augmented by [various policies and procedures]. That links to https://xmpp.org/about/xsf/council-policies-and-procedures which links to the bylaws

https://www.isocfoundation.org/grant-programme/emergency-response-grant-programme-covid19/ > Demonstrate previous experience in managing grants of at least US$250,000 within a one-year period. Experience in managing subawards to local groups is desirable as well. > [..]

I think we fail at this at least

I agree.

We can still give it a try, but we'll have to come up with an "innovative solution" in the next 4 days

Maybe it's our time to propose bitcoin, blockchain etc.

I'm not in favor of embracing that just for the purpose of obtaining that grant.

I am also not available to work on this in the next 4 weeks.

Sorry I should work in making my sarcasm skills more obvious :)

What project do you want to pitch? Just the xsf in general?

If we want to pursue this, we need to move fast - I will personally not be able to do that. To many obligations/responsibilities that I cannot postpone, this month.

From what I read, I'm thinking that any proposal should have a covid-specific nature.

I don't know. It's not like XMPP wasn't already present during this covid situation, /me eyes Jitsi-Meet

So I'm also curious as to what to pitch yes

We could make an offer of support though. XMPP is already used in a number of places within COVID-19 response, after all.

As "the XSF" make an offer of support?

Yes. I'm not sure how that would work in practise, though.

dwd Your employer is in a specific position to would have had the need for such support, if anyone, I guess. No learnings from that?

specific XEP development? Implementation effort?

Would be nice if we could combat Covid19 with MIX and get funding for that. 😃

and have MIX sorted overnight 😃

We haven't needed such support (much - I've asked for help from a handful of people for specific cases). I was more thinking in terms of complete newcomers to XMPP wanting to do things in that space.

MIX?

huhuhu

hey it's only been over 4.5 years I'm sure it'll be widely implemented any second now

quick poll: are CSI and Push notifications part of what needs to be addressed by message routing / IM-NG?

Yes

here I slapped together a thing so we can keep track of MIX progress, but I suck at CSS so patches welcome https://www.moparisthebest.com/mix/

moparisthebest, I can't believe you didn't register "arewemixyet.?"

Ge0rG, Uncertain

that would be a good idea :)

moparisthebest, there are quite a bunch of implementations nowadays.

Incomplete impls for sure

Or not really adopted

Or hidden behind flags.

that also

Or in someones WIP stash

@guus @dwd the usecase for XMPP in coordinating humanitarian response and distance learning is of course very strong. A grant proposal could be aimed at easing up deploying of XMPP in the right way, a kind of creating a streamlined develop journey. I only have no time to write a grant proposal for that: am already bouncing from my second into my third proposal to write this week...

Link Mauve, I'm aware of a bunch of incompatible and incomplete implementations, don't think they count towards adoption though

just seems like in the XSF if a standard is good, it's adopted rather quickly

so if something can go 5 years without any adoption, you have to wonder, is it actually good

moparisthebest, we just got a presentation of Kaidan’s MIX implementation, it works.

I’m not aware of any incompatibility from the XEP.

If you find any such missing bit, I’m sure they’ll be happy to fix it. :)

with what server? what version of the XEP

let's all use kaidan then so we can all communicate via MIX :)

all have to use that specific server too right?

pep., Conversations also exists.

moparisthebest, Tigase AIUI.

ok so everyone running anything else can just throw it away, and set up Tigase, when is the flag day scheduled for?

moparisthebest, why would you want a flag day?

oh, I don't, flag days seem destined to fail, but doesn't MIX by design require a flag day?

I don’t believe so.

because you need support in *your* server too, in addition to the remote one?

where's that defined?

There supposed to be a MUC compat layer ✏

moparisthebest, in XEP-0408.

And PAM in XEP-0405.

that layer is optional, not required for MUC core

MIX core*

right

does anyone implement it?

rather, does tigase, since apparantly there are no more server implementations

as an optional feature, but we've already added it

Andrzej, btw, could you give me a JID on some Tigase server with MIX support?

sure

moparisthebest, Ejabberd and OpenFire both also have an implementation, I don’t know their status.

I also started an implementation, which definitely isn’t ready yet.

last I heard it was like "we implemented a super old version of the XEP, so we are now incompatible, also we never did any interop tests anyway"

that could have changed since

(in case of Openfire, it did not)

How do I, as PEP subscriber, know that my publisher knows that I want to be notified about something?

flow and me are having fun with PEP and CAPS. subscriber adds a new disco#info feature of something+notify, for which a presence update with a CAPS ver element is sent out. Before the server performs a service discovery query to decode the 'ver', the publisher publishing something. Server has not yet decoded the 'ver', and thus does not send a notification to the subscriber, that by now expects one.

subscriber is not guaranteed to get a disco#info query, as the 'ver' might already be known - unless you add something that's guaranteed unique, but that kind of defeats the purpose of 'ver'.

Doesn't PEP send the last item on subscribe?

subscribe is implicit, and already in place

Could you rephrase that as a Scansion script? :)

https://pastebin.com/hZ3WZkEK

on line 10, the intended recipient of the notification sends out a new presence update, with a new caps 'ver'. on line 17, the publisher publishes the item for which the intended recipient should receive a notification. on line 29, the intended recipient receives a request from the server for disco#info (which the server will use to decode the 'ver' hash). That does get responded to, and that response does include the mood+notify feature. However, before that response makes it back to the server (potentially even before the server made the disco#info request) the server already evaluated CAPS, and determined that the intended recipient did not (yet) have mood+notify. Thus, it does not get sent the notification.

What if you broadcast the last item on filtered -> unfiltered state transitions?

can PEP services disable filtering?

Not that I know of.

I'm sure if you look through XEP-0060 you'll find an option for it.

Filtering seems hard-coded unconditionally in Openfir ecode.

Prosody until recently implemented PEP filtering by adding and removing subscriptions dynamically, but we changed it to generate the subscriber list from cached caps on publish instead. And when receiving a new presence it does a diff of what +notify are advertised and resends the last item for new ones.

Internal implementation detail, but the end result is that you get the last item of everything you want, when you start advertising interest in it.

I /think/ it should be relatively safe from the kind of race condition you're describing.

Yeah, that seems fine.

so we add "send last item on new +notify" to the pep xep?

I wonder what ejabberd does, since I usually run sinttest against ejabberd and never had the issue

> Prosody until recently implemented PEP filtering by adding and removing subscriptions dynamically, but we changed it to generate the subscriber list from cached caps on publish instead. Funny my plan was to change ejabberd the other way round.

Zash Prosody does send an advertisement of something potentially published a long time ago though, with that strategy, doesn't it?

(unsure if that's bad though)

Holger why?

Guus: Yes. That behavior goes way back.

Tigase behaves the same as prosody

if node has "send last published item on subscribe" I think that this is a correct behaviour

I'm not certain it's entirely correct according to the specs.

It is however useful, otherwise clients would have to manually fetch everything, wouldn't they?

https://xmpp.org/extensions/xep-0163.html#notify-last

Guus: I feared that question. I'm tired and won't get the details of the corner cases I ran into right, right now. Sorry. "Dynamic subscription" seems the more straightforward way to me as it just re-uses all logic for explicit subscriptions as good as possible.

no worries

Holger: As in treating a bag of +notify as a series of pubsub (un)subscribe requests. We changed it because it caused a lot of IO since we added persistence support.

Holger, the important question is: do I get the last item on +notify presence with ejabberd now, and will I get the last item after you change it in ejabberd?

flow: I would expect you get it already but only God really knows how ejabberd's PEP behaves.

flow: And yes certainly afterwards.

(Assuming the node is configured to do that.)

Zash: Yes my one difference to the handling of explicit subscriptions would be to throw +notify subscriptions into some RAM table.

We filtered those out, but it still went on to save the now mostly empty node settings.

Also, do you implement https://xmpp.org/extensions/xep-0060.html#entity-subscriptions or https://xmpp.org/extensions/xep-0060.html#owner-subscriptions on PEP?

Or, did it, like for us, carry over from a generic pubsub implementation?

Guus, can I configure PEP nodes on Openfire so that they send the last published item on new +notify?

Is it possible to configure a PEP service to *not* do that?

Also s/is it/should it be/

flow: it's not configurable in Openfire, and, given that the test fails, Openfire doesn't appear to send the last published item on a presence update. I'm not even sure if the last item is sent when the subscriber comes online.

If it does, it does not wait for any CAPS ver value to be resolved. That in itself is not very promising.

Zash, dunno, Holger threw in a "assuming the node is configured to do that" ;) guess configurability is usually a nice thing to have, the question is the default ✏