XSF Discussion - 2024-02-28

so I'm thinking about what'd be needed or sensible for a Pronouns XEP. I.e. a way for people to announce their preferred pronouns into a conversation. I was thinking to make it part of presence, which has the upside that it immediately (without extra code) propagates to all peers (including MUC). It also has the downside that: - It needs to be configured per client - There is no way to control propagation of that information to untrusted MUCs. I lack knowledge of the needs of the primary users of such a feature and I wonder whether anyone can close that gap?

an alternative implementation would use a PEP node (or maybe vcard), which do not need support by all (emitting) clients (only one), but doesn't as easliy propagate to MUCs.

(but has the advantage of fine-grained ACLs if necessary)

It has been discussed a times here already iirc, well vcard support rather.

But yeah rich presence may be better for propagation :/ ✏

vcard has the downside that you can't ACL different fields differently.

A user might not want to expose their real name to a MUC, but exactly because of that they may want to transport she/her as pronouns.

Maybe the best move is to make this possible? :/

Or have different vcards for different mucs

MEP when

pep., I don't think that making sub-parts of a complex XML structure in PEP (or vcard-temp even) ACL-able is a thing which is likely to happen.

Yeah..

MEP though.. :p

what's MEP again?

316

is that for users to write to?

Basically make it possible to publish stuff on the MUC's node

I guess?

I thought this was more of a thing for MUCs to use to broadcast stuff

not for users of MUCs to have MUCs broadcast stuff on their behalf

I guess it could be both

Some nodes could be writable

and then publish an item per user...?

That would also allow for different avatars, omemo keys

Yeah

oof

that needs a well-written spec on top of MEP even

to ensure that stale data is deleted when a user is (permanently) removed from a room.

and to prevent that users can write over each other's data in the same node

True

in the end, a huge effort. while I can see the use, I'd like to not block on that.

the question is whether *always* exposing pronouns to a semi-anon MUC is a problem or not. I truly cannot judge that.

given the overhead of PEP I would rather not create a pep node for every indivdual field of vcard

jonas’: "it depends"?

pep., that means "yes"

because the question contained "always" :)

s/yes/yes it is a problem/

not sure if that was implicit here, but then there's no corollary to me saying that it's always false for non-anon rooms ✏

i would like pronouns to have permissions

because it depends when you want to expose them yeah. like specific group chats may not be reseptive. or maybe you have a anti-trans uncle or something

> vcard has the downside that you can't ACL different fields differently. that seems like a *major* downside to vcard. is that for current vcard? ✏

yes, unless someone knows more than me on that.

sorry i wouldnt say thats a "downside"

seems excessive to me to have every possible filed have ACL

lovetox, what other solutions are there?

none probably we have currently

do you have any better idea?

but does anyone know a service or example where this is provided?

isnt that vcard supposed to have your nickname, picture and rest of the profile stuff

my idea is to not do it because of cost/benefit ratio

not having acl there seems like a complete miss

MSavoritias fae.ve, yes and no

we have acl MSavoritias fae.ve

you can decide on a per jid basis, who can see your VCard

what you asked is, on a per JID / per field basis ✏

> you can decide on a per jid basis, who can see your VCard well that seems still bad imo

i know some social network can set on a per field bases permissions, but also only to whole groups like, facebook "friends", not a per user basis

if vcard is supposed to hold your profile and you cant restrict said profile

im not saying that it couldnt be useful to someone out there, obviously i cant judge that, my opinion is, that its huge technical task, for very very small amount of users

MSavoritias fae.ve, i just wrote that you can restrict your profile on a per jid basis

your *whole* profile

right?

yes, thats what you call a profile

what you mean is "field"

yeah seeing here https://xmpp.org/extensions/xep-0292.html#self-pep-retrieval the profile has basically anything

like even address

only if you set it

dont know what you are getting at, facebook has also a huge profile with everything, no sane user fills it out

well of course you cant set it because xmpp doesnt care about safety or privacy here

anyway. i already have some ideas. this just shows that vcard should use that framework too

which ideas? :)

while your at it, also show how a UX looks like where you configure that all

I mean setting permissions to "groups" would IMO suffice, and there's precedent for that. XEP-0060 does allow specifying access by roster group membership, for instance.

but we need some other, non-static groups, such as "non-anon MUCs", "semi-anon MUCs", "that specific entity"

per-groups profiles ✏

Maybe rather than per-field ACLs

vcard with acl per field def. sounds better than one pep node per field

separate vcards could be easier on the protocol level and clients could expose it the other way around to make management easier.

yeah

Clients can get around it UI-wise. We can propose suggestions

I think I also lean towards having fully separate vcards at the protocol level

then the question becomes how you configure routing of the vcard request IQ to the correct endpoint on the server-side.

The vcard4 IQ? :P

that, yes.

by correct endpoint I mean "the correct vcard for the requesting entity"

The vcard request iq was removed, it's just pubsub now ✏

Zash: yes, we'd need to add it back 🙂

or can you set ACLs on items?

S i g h

Isn't pubsub just fine?

jonas’: you can't

I'm not sure I get it

then we indeed have a problem. ✏

A server knows if someone is in the requestee's roster no?

If we just care about rosters

pep., yes

pep.: and the requesting entity just looks at both nodes or whichever it thinks it ought to see?

"both"?

Public vs private

eh

I don't think two is enough.

How many do you want?

I'd expect N nodes.

Sorry I'm lost

Yeah N

pep., user requests vcard as pubsub retrieval to a fixed, well-known node. The server needs to decide which of the many vcards to return. Pubsub does not support that.

Does anyone have an example UI for that? 🙂

I'm all for privacy, but too much complexity for the user can seriously harm it

MattJ, well you don't need to make it overly complex UI-wise, but you can allow for configuration

MattJ, yes. visibility settings like "Only mutual contacts", "Mutual contacts + private group chats", "Mutual contacts + all group chats", "Everyone", on every field. The client then composes the vcards and publishes them with the matching ACLs.

potentially even "Mutual contacts in group X"

:/

that sounds basically like google + circles :P

yep.

jonas’, fwiw I'm not sure I want a "private group chats" / "public channels" dichotomy like you said above for this too. (especially not paired with mutual contacts). But I guess we can review peer groups one we sort out the how

sure

(Think family private groupchat where I haven't said anything yet)

MattJ, I think even snikket has three levels already, doesn't it?

Yes

maybe lets start by sorting out trivial things like mentions first :D

That's another problem

That can be solved in parallel :)

Mentions involve text, I like to stay out of those after the Big Markup Flamewar. Too much fire and burnout in that.

:x

MattJ, similarly to how snikket restricts the options there, I think clients would generally do that, too. The protocol level benefits from some simple flexibility though, IMO.

I agree, but we've also seen time and again that overly generic/complex protocols don't get implemented

or that they get implemented the way XEP-0016 was implemented

hence "simple flexibility" :)

indeed.

Many people around today probably don't remember XEP-0016 UIs

But it's a good example of how protocol can lead to terrible UIs

I can't remember which client started the trend of "let's just make a simple 'block' feature on top of XEP-0016", but it was good

right

But hard to pull off reliably without a simpler protocol that matched those semantics, hence XEP-0191

Then we had that translation logic on the server side for a while, but that also wasn't super reliable

mhm

the obvious translation of the UI I suggested to protocol would be to indeed split the fields into different nodes and apply ACLs

max i would do is, public/privat

but then you end up splitting vcard4 into a flock of pubsub nodes which does, indeed, cause overhead.

You said we need N versions of the profile earlier, but is N really unbounded?

Can we not manage it with 2 versions, with appropriate access controls on each?

I'd argue that no, it's gonna be meh, but I'd be willing to see where that leads to

MattJ, can we make an escape hatch for >2?

if so, I'm game.

I guess what I'm gettin at is: do we need to present different info to different entities, or only control the visibility?

If we present different info, how many different kinds of info?

different info would be good

Because I think that's what determines how many nodes we need

I'd like to consolidate MUCs on a single JID

but I can't because avatar.

Reminder that I'm in the "JID per persona" camp, so that influences my thinking on this

Avatar being particularly relevant

right

please fix my poezio then

to support >1 account.

tmux :)

:(

noooooo

jonas’, I wish

But that will likely never happen

And yeah no I'm also tired of "use a different account" tbh

But then how long will it take for poezio to get a profile editor UI that supports everything you want here?

MattJ, I don't need to, I can use another client to set up the profile.

I already have ~7 accounts and it's a pain to manage. Plus yeah not all clients supporting it ✏

Well we need better support for multi-account in clients, not spend the next 10 years trying to get everyone to build a sane flexible profile editor

Which will invariably lead to unintentional leaks

MattJ, okay, I can buy into that.

different JIDs does have a significant advantage.

fixes a bunch of stuff at once.

I don't know.. I still think there's value in providing some kind of privacy ✏

pep., so do I

and then two levels may actually be sufficient-ish.

That doesn't rely on having to create different accounts

you people have different accounts? :P

Why not?

MSavoritias fae.ve, I do

MSavoritias fae.ve, at least four, I think.

probably five

im too in the camp of one account with permissions btw

depends on whether you count my notafrankensnikket

In some cases you don't even want the two correlated by their actual address

And you can't sanely fix that with protocols

XMPP is not that though

it can use gns to do that. but its ot to current discussion

and gnunet is not XMPP, similarly

Account isolation is built into XMPP, it's a feature we have and should build upon

Someone still needs to fix omemo and vcard-te^Wwait..

its mls now :P

Same issue

We'll need to fetch keys somewhere

MEP when

Do we have basic message delivery reliability yet?

Zash, where've you been? :)

wair we dont

oO

Zash, if not omemo, yes.

MattJ, in the world where only Prosody does s2s-XEP-0198 ?

:)

we've reached a reliability quote where people are not complaining anymore.

The world where I can't see what my mom writes because of omemo, on some devices

I still have issues with gajim that I need to debug at some point re omemo.. (not being able to read messages when gajim isn't online)

(which is.. ?!?)

so more arguments for me to implement OX i guess :/

I'm not entirely sure the encryption mechanism is responsible here..

very likely it's at least related. per-device keys + forward secrecy add a lot of moving parts and sources for issues.

yeah that is my thinking too. plus with nomadic identities forward secrecy seems unworkable

Yeah but it feels like another MUC/MIX thing when someone mentions something wrong with OMEMO and that OX is then the obvious solution

Not that I don't want OX mind. For different reasons, in different contexts

We need OXEMO

OXEMLS

Perfect

Probably. just like we need MIC, or MUX

why not OMEXO

I've also heard re OMEMO that we need OX because handling keys with OMEMO is hard and having one key makes it easier, but nothing says OX should have only a single key, it's just that a bunch of devs got together and said "yeah ok let's do it this way"

It can also be done with OMEMO and has been discussed many times already

and given that OMEMO is widespread already, I think that approach has some merit

the problem personally is that my usecase is: > The account a person has is completely portable and independent from the device/app that it is used with and is backed up so that it can be recovered using social trust.

and > This library has an account that is basically a "hub" that collects all the other subaccounts. This way a person can have a gaming account, family account, friends account and so on. > This needs more thought on how it will work. and specifically safe enough so each profile can't be linked to the other one or to the account. or that knowledge of the main doesn't disclose the profiles. > The account with all the profiles can be exported and imported on the fly. it can also be only portable mode where the apps keep no information after the person "logs out". This would be the default for untrusted devices. > The export also holds all the messages and media and everything. can be granular.

MattJ, indeed

i bet its going to be difficult to make omemo work here. to my understanding at least

ping to singpolyma

Good day to one and all

What do you think of form caching? The forms to cache that I think of are those to input data into.

Suppose I have a contact for bookmark managing (i.e. bot). 1) I am generally offline. 2) I find a URL address I want to add. 3) I open the list of ad-hoc commands and fill the form to add a new bookmark. 4) Once online again, the forms, one by one, will be sent to the bot.

https://daniel-lange.com/archives/186-Opencollective-shutting-down.html fyi

Link Mauve, what do you think of form caching? ✏

I'm not certain given the lack of context, but it may be related to https://www.opencollective.foundation/ rather than https://opencollective.com/

the post links to the second opencollective blog directly in the beginning https://blog.opencollective.com/

Yeah, I suspect the author may be confused (as it is indeed confusing)

They probably have a project hosted by OCF

the email they give also points the second opencollective. hmm

> OCF was created by Open Collective Inc. (OCI) such confuse

lets wait for an official announcement

Shutdowns like that are so frustrating. What were they doing for it to become suddenly unsustainable?

i remember reading opencollective wanting to become a DAO in a blockchain

(the second collective)

but idk what happened with that

and they take 8% of project funds? https://www.opencollective.foundation/#pricing

> We responded to increased demand arising from the COVID-19 pandemic without taking the time to establish the appropriate systems and infrastructure to sustain that growth. > > Unfortunately, over the past year, we have learned that Open Collective Foundation's business model is not sustainable with the number of complex services we have offered and the fees we pay to the Open Collective Inc. tech platform.

The XSF doesn't pay any fees to OCI (because the XSF doesn't take any % from projects)

and if they can't sustain the complex services, can't they just retire those, whatever they are?

Rather than throw hundreds of projects into disarray?

Anyway...

what are the alternatives now? besides liberapay

The likely news here is that OCF, not OCI, is shutting down, so there are many other fiscal hosts (including the XSF, for XMPP projects) to choose from

ah so the collective that manages the payments shut down. oh well

I don't think you even need a fiscal host to use OCI if you manage your own bank account and accounting

(which is equivalent to Liberapay)

the thing is i cant take donations in finland

its illegal

OCF was a generic fiscal host that you could use, if you couldn't find another (so if you're not an XMPP project, you can't use the XSF, but the OCF allowed more general projects)

but probably that is not solved with a fiscal host. not sure

Not sure either, sorry

no worries. i do have an xmpp project i would like to make fiscal host at some point tho

if i can work it out. hence me asking

ah found a better source https://opencollective.com/opensource/updates/regarding-the-announcement-to-dissolve-open-collective-foundation you are right its the fiscal host. > You may be aware of recent developments regarding the dissolution of Open Collective Foundation (OCF) by the end of the year 2024.

reading through https://xmpp.org/community/fiscalhost/ how many of these are hard requirments?

like i do have a chatroom and its an open license and open source

but i dont have an "active community". like multiple commiters or an issue tracker

so what are exactly the roadblockers here? or is this the wrong venue for this?

This is the right venue

The criteria in the first list are not necessarily blockers, as it says, exceptions can be made. The main purpose is to ensure the projects we host are "real" XMPP projects, rather than someone just publishing a 5-line Python script that uses slixmpp so they can apply ;)

probably its a bit early still. espesially since the finnish thing takes 5-7 months apparently to be approved. but i am interested to know what to "prepare". Im talking about: https://git.sr.ht/~msavoritias/Guile_XMPP https://git.sr.ht/~msavoritias/Applesauce and xmpp:guile_xmpp@conference.magicbroccoli.de?join

> The criteria in the first list are not necessarily blockers, as it says, exceptions can be made. The main purpose is to ensure the projects we host are "real" XMPP projects, rather than someone just publishing a 5-line Python script that uses slixmpp so they can apply ;) ah mine has like a couple of dozen pages of docs but no code yet. but hopefull soonish

The XSF has to make declarations about its income and outgoings, and we need to ensure those stay true

ok? what was that a reply to

So it's not that a 5-line Python script would certainly not qualify, but as there is some overhead and risk involved, we can't take on just anyone

ah fair. thats why i asking how to make this "legimate"

Tick as many of the boxes as you can, apply, and it will get discussed... we'll find out

ok. i will apply for the finnish thing and try to write some code until then. hopefull i have issues enabled by then :P

And at least you'll get some feedback if you're not accepted, so you can perhaps try again later if it's nothing major

sounds good

Google keeps insisting that 'mam muc' is some kind of query for an Asian squid fish sauce. The personalized search result cake remains a lie.

The XSF should spend its budget on boosting those keyword the correct way.