XSF Discussion - 2021-02-12

gentle reminder for 20-21 submissions 😁

There is still time!

thanks already to Sam and Thilo ;)

there is! hence the reminder

I’m still lacking inspiration

how would 200 imaginary euros inspire you?

more like: what to put into the application

content-wise

the joys of developing with aioxmpp?

If jonas’ doesn't want the imaginary euros I'll gladly take them off your hands

sold to the Matt with the J!

I'll try not to spend them all at once

14 reasons why you you should start using jabbercat NOW! number 4 will amaze you!!!!!!!

Inb4 "How I got 200 imaginary euros" by MattJ

:D

"Implement Passive Income with the XMPP Standards Foundation"

pubcoin - a pubsub bitcoin model for online payments

"How we brought back the <payment-required/> stanza error"

that one secret all xmpp developers don't want you to know

I'm making notes

cool 👍

"How async day saved the, a tale of+++CARRIER LOST"

that's enough fermented potato juice, Zash

Not enough you say? Well it is friday after all.

skål!

20-21?

oh, summit 2021? Sorry, wasn't sure what submissions these were or how I'd submitted one :)

can you claim lack of coffee?

No, plenty of coffee this morning, just didn't know what "submissions" meant without context and got confused by the 2021 with a typo (I assume) dash in the middle :)

"submissions" is SMTP over TLS for email submission, silly!

no typo, it's 20-21 (Feb 2021)

such confusion

02-21?

/[-012]+/

no, 20th - 21st february ✏

ooooh, it's a day range

.oO(21st february fox)

the 22st will confuse everyone

Almost time for the board meeting

Ralph, dwd, Seve, mattj

Hey

Hey

Just flagging everyone because I know it helps remind me

ralphm: are you here? Realizing I spelled your name wrong before

Okay well we have quorum in any case, do we have an agenda?

I'm not aware of any

The only agenda item I would have is gsoc and nobody has submitted any project ideas yet

And at 15 minutes after are at the point of having to cancel the meeting

I'll put something on the wiki today.

I would also still like to re-add if the agenda is shifting a discussion about the XSF acting as a fiscal sponsor for XMPP related projects.

Yeah we have barely even discussed outreachy

arc: actually, I don't fully understand what the wiki is asking. Does it want a list of gsoc teasers or the full project that would be the gsoc task if someone were to subscribe?

Project ideas just like previous years.

I will write an email too members@ though I am fully aware that most people just ignore those emails

Neustradamus: I don't want to get into an edit war with you on the wiki, but I changed the title of that SASL/SCRAM page for a reason, why do you think it needs a list of every possible mechanism on the home page?

I read all the members@ mails.

I stand mistaken

Kev doesn’t, therefore most must be wrong :D

SamWhited: it is for search engines. ✏

Your point is valid and accepted. I was mistaken

Neustradamus, the wiki is for people, not search engines

The wiki is indexed in search engines.

Neustradamus: that is not useful, the main page doesn't need to be what comes up when someone searches for a specific sasl mechanism. The page in question will have them listed, that seems good enough. I am going to undo that edit, it just clutters up the main page.

Does our robots.txt even permit search engine indexing?

Though I would find the methods interesting, they could be on a sub page?

It is really important

Official sources are on it

Neustradamus: giant bold lists in the sidebar are not important, I promise.

The official source is already the page itself, which still has all of these mechanisms listed.

Which help people.

They don't need to be listed every single place that links to them.

One day I will figure out how to add links on this wiki… after like 4 tries I finally remembered the syntax, but for one link it works and for the second link it doesn't even though they appear identical *grumble, grumble*

arc: added a possible project that I think will be big enough to take up the whole time

Cool thanks

Actually, going to add a second one that I care less about but which might be more useful to the community or more interesting to the students, I assume it's okay to have multiple and the students pick what they want to do if we get some?

> A list of teaser tasks is given in the Project Ideas overview arc: does this mean we should add a link to teaser tasks too? That's what was confusing me I think

Teaser tasks are for students who are applying because we, like most organizations, require students to contribute some code as part of their application process

Though I'm not sure how the wiki was intended, I really just copied last year's format

And yes you should provide several ideas for students, and keep in mind that students are not required to select from the list

thanks

I *think* how I used to do it was to have the Projects listed on the XSF wiki, and the teasers listed on the software group’s pages. I neither pretend that it’s impossible I misremember, nor that this must have been optimal.

I'll go back and look how it was done in past years, thanks

i, for example, used to tag certain issues as 'teaser-task' and then linked to a filtered list on my issue tracker

The task list is the most important thing. That is required to actually submit an application

I reformatted the page with a few project ideas and linked to my "Good intro tasks" tag, although maybe for GSoC students I should add some more difficult stuff. We'll see if anyone is actually interested then I can direct them at other issues I guess.

Hello

I dislike several things about XEP-0389 data forms.

First of all, I don't like that forms can have a title. I think that the client should make it clear that it's a form sent by the server or an evil server (I know that registering on an untrusted server is bad) can make the client show a form that would look like a form to log in to a trusted server.

I said more about it here: https://github.com/dino/dino/pull/990#discussion_r575390603

Another issue I noticed is that servers might present the same elements under very different UIs. Let's take the ToS as an example. Some servers can show it in the instruction, others can put it in a fixed field or as a label of a bool setting.

Were there any attempts to improve the situation?

There was https://xmpp.org/extensions/inbox/tos.html

And data forms are defined by XEP-0004, not 389. And we all hate it, but also don't really want to change it since it's used by everything.

And they do present quite an UI/UX challenge.

Only Gajim implentented 389 fully and can show forms from every server correctly.

389 is implemented? This is news to me

Dino has partial support, that I tried to improve and Siskin also.has partial support.

Conversation and Monal.don't support them at all

See this

I didn't realize that, good to know. I'm all for defining different challenges, I hate dataforms, it was just the thing that's available so I used it.

https://lebihan.pl/xmpp-upload/index.php/57052777-b4d4-4d10-b0fa-3db30420883a/cN-Gzj4MRSyAHowu1oo-Ow.png

Or the screenshots under https://github.com/dino/dino/issues/988

Gajim does not implement 0389 ✏

That issue doesn't look like 0389 either

mimi89999, ibr is defined in XEP-0077

lovetox: What do you have then?

0389 trys to make 0077 better, or have a different more flexibel approach

but its not supported by anyone yet to my knowledge

and it does not change forms in any way

OK. 0077. Sorry for the confusion. I looked at 0004 for the form spec anyway.

s/389/077/

> The XMPP ecosystem has no way to allow clients to display or refer the user to the Terms of Service and Privacy Policy of any given server. Well, IBR forms are a way...

Most things don't support that though and they're not wrong that this is a major issue for any service that wants to use XMPP and allow third party clients.

Whoever "they" are.

And that's part of the reason for 389, to have a better framework to solve that kind of issue.

They it's probably jonas’

Yah, it doesn't actually solve this problem yet, but if we can get to a place where most things support it hopefully it will be easier to add a standard "simple" registration method with a few common fields that everything can implement easier and it will spread quicker than forms (I hope)

Of course, it relies on implementing a new framework for sending forms first, which is even harder to get implemented than data forms in 0077, so it probably just doesn't solve this issue.

Some clients already support IBR forms.

"some" is not "most" unfortunately. And it's very few I suspect.

Gajim has full support. Dino has partial support, that I tried to improve and Siskin also has partial support.

That's still not "most", though thanks for trying to improve registration support :)

https://github.com/dino/dino/issues/988

Point is that it's hard to do, so a lot of clients don't, which makes a company wanting to implement things on XMPP less likely to allow third party clients (I suspect)

Why would a company do IBR?

Because they want you to be able to download their app and sign up for an account on their server.

But that's why I'm saying I agree with the person who said "XMPP ecosystem has no way to allow clients to display the TOS" or whatever, like you said, there's technically IBR, but it's not widely supported and has the bugs you mentioned, so it's not really a good way to do it and people won't use it.

That would be quite easy to do. The form would be known and static. They could also just display the form on their website with webview.

Sure, that's what they'd do instead, but that's not part of the XMPP ecosystem and won't work on third party clients

That's why I'm suggesting your original quote was right: there's no good way to do it in the XMPP ecosystem, so companies will put their website in webview instead and won't allow third party clients.

The forms allow for too much customization, that's why they are hard to implement

I agree.

It is a blessing and a curse.

what's the status of the tos xep?

I spent ages trying to do a data forms implementation recently (well, trying to fix an existing broken one, this is like the third or fourth time I've tried to implement it) and even after figuring out an okay way to do it in the end I still ended up not being able to support the multi-item form stuff. No idea how I'm going to make that work.

tos xep?

https://github.com/maranda/metronome/commit/89f49ee2f4cb6825c19f9d60b6aae00435d5614f

The one in inbox? Wasn't accepted.

That's .. just a form field

Metronome just went and implemented ToS with exactly one client I know being able to display it: Gajim.

> The one in inbox? Wasn't accepted. Why?

I missed that one somehow and don't see it on standards@ or in my inbox; link?

Or rough date range if it was a little older?

2018-05-something

ah yes, that is older, thanks

https://logs.xmpp.org/council/2018-05-30?p=h#2018-05-30-258449810c08bba6

Also, ToS isn't the only thing admins want. Some are asking for mail, others use custom catchas...

oh yah, I remember this now. Yah, it seem(ed|s) like it's just duplicating forms except with fewer options. I would eventually like to have something like this as part of whatever eIBR/SASL2 combination we eventually come up with.

Also pre-auth IQs. Maybe it's time to revive this one and fix some of the issues.

forms in IBR isn't all that widely supported, which I suppose is what mimi89999 is talking about

Yes

Anything other than username and password usually limits you to certain advanced clients.

Yah, probably good to have a simplified version. Just not one that also mixes in form elemetns and has most of the same extra stuff as forms.

Even Conv doesn't do it.

XEP-0077 has existed for ~18 years. We can't force clients developers to implement things.