jdev - 2021-12-21

Got more answers on the form, thanks for answering! https://framaforms.org/xmpp-code-forge-1639934950 reminder for those who haven't seen it :)

Spoiler alert, it's alldifferent answers atm ✏

lol

pep., the basic set of requirements misses "federation with github.com/gitlab.com"

Federation?

There's a lot of things that go behind this word ✏

Oauth?

OAuth at the very least, but I'm more thinking of true federation of PRs/MRs.

lets make a new XEP-xxxx: GIT over XMPP

jonas’: I'm not sure what that means

Is that a thing already?

no, it's not

Then I'll include it in my wish list for Christmas

Of course I'd like federation

If you add gittea though they are working for federation with thn forgefed/forge friends specification

I'm sure that'll work with git{lab,hub}.com

How would it even work? These things all have slightly different workflows (even if you don't have CI pipelines)

Also, can we authenticate to this new forge using xmpp? We can assume everyone already has an account there, right?

Obviously never XMPP, can't have nice things you know

I'd guess ActivityPub

Yeah its on top of activity pub. jonas’: with github/gitlab lock in is a feature not a bug.

> lets make a new XEP-xxxx: GIT over XMPP Where Mercurial fans 🙃

If an application uses multiple PEP nodes with whitelist access model, is there a way to make sure, they have the same whitelist? I'm worried, that a JID is added to one PEP node, but it fails for the second one, and the application would not work because of the mismatch. Any idea?

I don't think so, unless the whitelist happens to be the roster, in which case you can use that :)

sounds like a job for a new XEP: pubsub allowlist as node

Maybe reconsider whether it should be multiple nodes?

I think 0084 could have used a single node and notifications without payloads instead of the data/metadata separation

Except for that not being part of the mandatory PEP subset of features ✏

Zash I fear, that we *really* need multiple nodes for our use case. We decided against roster subscription, when we started implementation, but now I don't remember, why :-( I'm sure, it had a disadvantage, but what was it?

flow In the long run, that sounds like a good idea. Also for "social network" / "micro blogging". edhelas goffi to the rescue :-) For now, we will either work around the potential issues or change allowlist to roster and be bitten by whatever disadvantage that might have...

The actual "roster" access model (which uses roster *groups*), or the default "presence"?

Neither makes much sense without being tied to some user, like PEP

debacle: I think it could be managed with pubsub collections (XEP-0248)

Zash I wasn't even aware, that roster groups can be used for access.

goffi Is that implemented somewhere?

debacle: well Libervia Pubsub has an implementation inehrited from Idavoll, but unused and untested. Also I have a problem with permission management with collections for a long time, I need to make a PR and launch a discussion about that on standard@. Thus I'm mentioning it as an theorical option, but I'm not sure if this is usable in production in your case.

(my problem is that collection node permissions override the leaf nodes permissions)

Hmmm hierarchical access control lists?

goffi Maybe in the future, but now we need something, that can be used since two months ago ;-) Deadlines... I'll find my notes about what was wrong with roster subscription, print and burn them.

roster is about pubsub service roster, do you known a service which handles that? Libervia Pubsub also has a non-standard permission model to use publisher's roster, and it can be fine tuned at item level. But maybe if you can explain your use case it would be easier to find a solution.

goffi There is a client (= one JID) that does publish data on multiple of its PEP nodes, and some clients (= other JIDs) should be able to get that data. The data is related, so different allowlists would lead to complex error handling. I'm pretty sure, we could benefit from collection nodes at some point in the future.

yeah it really smells like a perfect use case for node collections.

maybe check which services implement it

goffi I think, that I checked prosody and ejabberd back then and both were not supporting that XEP, IIRC.

you can't try with Libervia Pubsub, but as I've said it's not really tested. Otherwise I guess you only current option is to use separated whitelist, and make feature requests on various Pubsub Services.

your*

debacle: Idavoll (the project from which Libervia Pubsub has been forked years ago) has pubsub collections and should be easy to install. Only issue is that it is unmaintained.

s/you can't try/you can try/

goffi We try to use something as mainstream as possible. Using XMPP instead of e.g. MQTT is already non-mainstream, of course ;-)

jonas’, my client gives me the following warning

(jabber.fr) Avatar mismatch: jdev@muc.xmpp.org/jonas’ 26ac2f84-c7a5-4022-a178-3c0ebf53cb77 != 37cba76057638d0b0a4aaa049d0a456ac64e4e82

sorry lovetox here :)

seems you announce a different hash then in your vcard is then found

Is there something defining filters on disco#items?