XSF Discussion - 2022-04-16

can someone write a simple status message in pep XEP

i think anyone would migrate to this in an instant

and we could safely ignore presence status message from that point on

and no dont put show in their or anything else

just the status message

lovetox: yes, you can!

i dont want to :/

maybe there is someone who is really bored :D

ok im writing this

👩‍💻

go for it :) ✏

<no-permanent-store/> should store until delivery to one device? In the XEP it only says where the message should not be stored (0136, 0313, chatroom logs). So what are other possibilities?

lovetox: i can help with that if you want

pep.: I guess that was the intention when I wrote it, yeah

Don't know where it fits with plans to replace the current mod_offline behaviour

https://github.com/xsf/xeps/pull/1177 I have opened this PR fwiw, I should un-draft it shortly

lovetox: I guess we first need a decent way to solve the issue of getting spammed with PEP notifications of things that haven't changed since last connect. PEP notification versioning anyone?

There's https://xmpp.org/extensions/xep-0312.html

larma, of course this would be nice to solve, but i don’t see how its a pre-requirement for any XEP that builds on pubsub

move status from presence to pep? I sorta imagined you'd take the user activity xep and remove the activity, leaving the <text> field pretty much

Maybe what should be done is to merge all the "User *" XEPs into one "User Status" XEP

We discussed at the summit how different apps have different status formats - e.g. some just show text, some emoji+text, some a picture or even a video

Right when that is removed from poezio :x

(and moved off to a plugin)

MattJ, if you mean by one "User XEP" one PEP node

this would really limit the functionality

as i can set different permissions for different pep nodes

which seems important, with stuff like location for example

Do you/users really care to individually set the visibility of what activity, mood and game you are playing?

activity and mood are obsolete if you have a user status xep

Yeah, location may be worth keeping separate. Also tune was one of the reasons that all these XEPs were made in the first place.

what matters is, location and tune

Because it changes frequently, and people were spamming <presence/> updates

while i could see how tune has no special permission, as its also not very privacy sensitive topic

location should be seperate

I was mainly thinking that if you want to stick a specific <activity> payload in the status, that would be good

and mood

and clients can just implement/display that or not

no its not good, its to complicated and from a time when no emojis existed

Okay, just deprecate them and switch to <emoji>?

just a <message>, and user can put in whatever he wants

or don't try for any semantic separation, and just <text> and leave it up to client UIs?

maybe in the future a, <url> to set a picture or whatever

If you want a client to interpret things in there, don't use "just" text. Otherwise it probably doesn't matter (but you may be limiting clients then to interpret things)

thats the point, i dont see why i want the client to interpret something

you should display whats in the text

that is waht the user wants to communicate

not a client on the other end that starts to interpret something

Maybe you don't have a use-case for it, (I personally don't either), but it's not a reason to limit it for others is it

The problem is that <text> is not currently the most commonly-used status type

It works as a baseline, but many modern apps don't use it

or use it in combination with something else

of course you can always extend with links to videos, pictures whatever

but text is needed

Agreed

A whitelist access model with nobody in it still allows one's own account right?

thats what we use for bookmarks

Ok

I can just redirect to 0223 I guess for the privacy model

Is the use of @id='current' specified anywhere?

I think it's in '60 under singleton nodes

yeah https://xmpp.org/extensions/xep-0060.html#impl-singleton

Thanks

pep.: nitpick: you refer to pgp e2ee xeps as examples of forward secrecy, but isn't the whole point of having pgp over xmpp is being able to decrypt archives with your one and only key?

I prefer?

Ah sorry, refer

:)

I took that from the previous protoXEP, maybe that's worth changing

I don't know if it's the whole point, but to pgp users that's definitely a feature yeah, I guess

Right 'the whole' is rather a hyperbole

If you have an idea how to rephrase this I'm happy to edit it

Just removing mentions of PGP there? First paragraph(?)

mjk, you can still use PGP and want your messages not to be stored forever on the device right

This isn't incompatible

Yeah, just remove pgp xep mentions, as they don't provide FS

Somebody getting hold of your device could "just" make it fetch everything again and *poof*, but I guess PGP users may be aware of this? (not?)

That would be equivalent to trusting the server's privacy policy I guess

And depends on archiving settings, and those seem to be usually turned on by default

They're enabled almost automatically by clients using MAM

(all of them)

They're actually turned off by default on servers

At least I know it's the case in prosody, and I think ejabberd?

Not sure if by clients. I know Gajim and C. don't turn mess with mam settings

Yeah but they just need to require MAM for prosody to turn them on ✏

Oh, that's some dark xmpp corner

(Is 'MAM archives' also a what's it called? ATM Machine thing.)

Currently I'm wondering if the minimal timer value should be in PEP so all devices of an account use the same value to prevent loops and all. Or maybe the solution to this is for clients not to send a new value whenever the sender sends something that is lower to the minimal value.

Maybe I should just drop the minimal value and set a minimal value in the spec, but then I have to decide of a minimal value and I don't know everybody's use-case.

Or I don't, and users will just decide between them.

Using PEP on MUC for this would have been nice though as there's an obvious node to go fetch

Yea, magic numbers in specs is no good. For some, it can be weeks, for others, minutes

I guess that's more of a social issue really and putting this in the spec is too much a hassle

If somebody wants their messages not to be readable well then they'll put 1 second and the recipient will complain.

(or 0 even, since that's allowed in the type)

Yeah I've convinced myself

> Is 'MAM archives' also a what's it called? ATM Machine thing. Answering machine?

No I meant to point out the repetition. The 'M' in ATM already is 'Machine'

The 'A' in MAM already means 'Archive'

Time to start using MAMA Archive

Idk, MAM is archive 'management', not 'archive' itself

I prefer saying just 'server archive'

Yeah but that can designate something different. Even though nowadays everybody does MAM

And MAM is a xep to manage that :)

You won't believe this, but there's another instance of 'Draft' on xmpp.org: > […] production systems are advised to carefully consider whether it is appropriate to deploy implementations of this protocol before it advances to a status of Draft. That's in the red carpet of experimental xeps. This Draft thing really dies hard, perhaps a `grep -R Draft .` over the entire repo is needed?

Yeah, that wasn't a very good idea

mjk, I updated the spec if you want to have another look :)

Too busy repainting the bike shed rn!

:)

https://http.xmpp.xyz:5281/upload/hJMoebU-CPeZ8QBp/pgCZZS_HQzCHhAtbSKJJvg.patch

jonas’: would this ↑ be alright, or are PRs much preferred?

For the record, the rest of the Draft occurences are either in xeps' xml, or in a readme (which doesn't seem to be rendered anywhere?)

pep.: > even though keys are deleted, message contents is retained both in server and client archives Effectively, when the ephemeral key is destroyed, the server-archived message is destroyed, as it now just consists of random bits. "Spooky deletion at a distance" is what I call it. :) So, when speaking of forward secrecy, server archive becomes irrelevant to privacy, only disk space

Or I should say "when _every_ recepient of a message destroys the message key"

Well, I think you understand the concepts, I'm just pointing out it's not very clearly expressed in that paragraph :)

> jonas’: would this ↑ be alright, or are PRs much preferred? anything which does not generate an email will be lost this weekend

mjk: ^

mjk, hmm, indeed. That's also original phrasing that I kept (just the first sentence in the paragraph). Any suggestion?

jonas’: okay then. It won't be lost in my repo, and I'll find time for github later :)

pep.: start with deleting 'both in server and ' and see if the rest sticks?

I'll need to look at the intro more carefully, can't right now

Yeah I just did that and the rest isn't too weird.. we'll see

Hey guys. Can anyone help me to pay for my xmpp.psi-im.org? I'll make a visa transfer to your card in advance.

Paypal/stripe do not work in Belarus