XSF Discussion - 2022-01-11

test

A+

Hi Kev, I am wondering if you have notes left somewhere from previous GSoC applications. Additionally, I wanted to ask whether you have input regarding experiences in organsiation / mentoring?

emus: flow has also been involved in GSoC organizing in the past. If you haven't already, you might want to poke him too.

emus: if you have a specific question feel free to ask me too. I've ran my own org for two years. But if you are just after some general information I think there are some ebooks out there on mentor first timer and org first timer

I don't have the link anymore but I read those when I Frist started

emus already reached out to me and I suggested that Kev may have some additional notes

Why is the certificate of this server trusted by xmpp.net: https://xmpp.net/result.php?domain=psynet.su&type=client While the certificate of this is not? https://xmpp.net/result.php?domain=igniterealtime.org&type=server Same cross-signed chain, as far as I can tell?

(note: the latter domain consists of two servers, which confuses things a little)

Daniel: Thank you Daniel. I just wanted to ask for experience or anything (lessons learned) that one wanted explicit to tell or recommend. I need to prepare the application now

https://github.com/xsf/xeps/pull/1144 do people really need to sign the CLA for this trivial stuff? cc @ board

My ex-board view: They don't need to "sign the CLA", but they do need to agree to the IPR policy somehow.

that is sign the CLA in our case

I think in *this* jurisdiction the change wouldn't have the necessary schöpfungshöhe in order to even qualify for copyright

Well, that's what I mean - the CLA automates the process, but if you can get a statement in any other form (including over IM) that should be sufficient.

"You OK with our IPR policy?" "Yeah".

About XEP-0060: When a JID, subscribed to a node with "Whitelist Access Model", is removed from the list, but not explicitely unsubscribed, should it get more items or not?

Without looking at spec or code, I'm pretty sure that if it no longer has permission to be subscribed, it should be unsubscribed

MattJ IMHO, the spec is not entirely clear. At least not to me: > A node access model under which an entity may subscribe and retrieve items only if explicitly allowed to do so by the node owner (subscription requests from unauthorized entities are rejected). The first part backs your view, but the last sentence blurs the picture. (I'm not a native speaker of English, blame me!)

Native speaker or not, I see no sense in allowing someone to subscribe, removing their permission and having them still be subscribed

MattJ Me neither! But it wouldn't be the first time, XMPP holds surprises :-)

:)

This error is explicitly specified to be returned to non-whitelisted JIDs requesting items: https://xmpp.org/extensions/xep-0060.html#subscriber-retrieve-error-whitelist ✏

> XMPP holds surprises :-) At least ejabberd does! Non-boring implementation.

Holger, but that doesn't imply that they don't still *receive* items :)

broadcasting items in reply to a publish is not, technically, retrieving

Holger, what does ejabberd do in the case where a JID's access is removed?

I'm fairly sure (without checking code) that Prosody will unsubscribe it

But of course I may be wrong

… let's better look now than tomorrow

it does seem to unsubscribe

MattJ: Better ask debacle about the details 🙂 They stumbled over the behavior, and I won't be able to check before tomorrow.

> Native speaker or not, I see no sense in allowing someone to subscribe, removing their permission and having them still be subscribed Me neither, the desired/intended behavior seems obvious.

looks like a bug in ejabberd, if my colleagues did observe carefully