XSF Discussion - 2023-11-07

Was there already some discussions and though about having a way to add a "trust" system on JID based on the network ?

Like other JIDs can "prove" that a JID is legit or something like that. ✏

edhelas: I reckon you are talking about something like verification in mastodon rather than e2ee

For e2ee there ist ATM

yeah if its for thrid parties to verify a jid is legit idk of anything being worked on. if its for a person to verify that the person sending the contact request is not a spammer i plan to start writing a xep for it one of these days.

> edhelas: I reckon you are talking about something like verification in mastodon rather than e2ee Yes indeed ✏ ↺

well the mastodon thing can just be added to the vcard of an xmpp profile no? from reading its just a link you add to your site. (unless we are looking for another solution.)

Keyoxide, too

right thats another good solution

https://snyk.io/fr/blog/verify-and-secure-your-mastodon-account/

Indeed, that's a very simple way to do it :)

And can be easily done within vcard

A small XEP to re-explain the flow in a XMPP client could help maybe 🤔

Is anyone aware of XMPP clients that do either 'mark unread' or 'remind me about this message in X long'?

> Kev: > 2023-11-07 11:31 (GMT+01:00) > Is anyone aware of XMPP clients that do either 'mark unread' or 'remind me about this message in X long'? thatwould be great

Probably weird in an IM setting? Maybe something à la Slack yeah?

I don't know of any

> Probably weird in an IM setting? Maybe something à la Slack yeah? Not at all weird in an IM setting. I often wish for a "reminder" to answer people later ↺

me too. reminders would be nice

Wasn't it possible in poezio to put the "unread bar" at some specific place? I don't really use this bar unfortunately

> Not at all weird in an IM setting. I often wish for a "reminder" to answer people later A "bot" like feature would do it no ? /remind-me 2 days ✏ ↺

I guess the interface depends on the clients. Implement it however you want :)

Any interest in standardising a PIP node for reminders? Presumably it's just ``` <reminders> <reminder at='timestamp' jid='contact' mam-type='[local|remote]' id='mam-id'/> <reminder.../> </> ``` or thereabouts.

Could this have anything to do with synchronizing read state?

I think they're unrelated.

Or, at least, logically distinct.

The 'mark unread' I do think they are. For the reminder, yeah ok ✏

Protocol-wise, I think 'mark unread' is just another application of synchronised read state. You're just setting the read state in PIP to an older id instead of a newer one.

PIP? PEP?

PIP=Private PEP :)

Ah ok

For whimsical reasons, we had PEP, PIP and POP.

POP? Open PEP?

https://xmpp.org/extensions/xep-0223.html was PIP

https://xmpp.org/extensions/xep-0222.html was POP. IIRC.

"You're just setting the read state in PIP to an older id instead of a newer one." hmm not if you're just unreading a single message

I don't see the value in treating read state as non-contiguous. I'm sure other people do, but it fails the complexity/value test for me.

Just like I set emails as unread in my inbox. I see value in it

I don't set all emails as unread until a past date

I should say 'read state [of a thread]'

That doesn't translate well in XMPP terms yet, but yes that makes more sense

Although really, I don't have the need to set unread state in clients that support reminders.

For how I use chat.

Maybe, but they're distinct features still, I think

Slack I use reminders, because it supports them, Discord I use Unread as a poor substitute, because that's what it supports.

You can also have reminders without setting a message as unread

Yes. For me, I don't need to mark as unread at all, if I have reminders.

I do accept that my way of using IM isn't the only valid way :)

I don't have much stakes in the reminder field, happy for it to be a thing, or not :)

I would prefer to have reminders than keeping single messages as "unread", as with reminders I can mark "to do" items in chat. I wonder if having a possibility to just mark single messages wouldn't be enough, but then, most likely I would like to have a multiple lists with those marked messages....

unread is insufficient

because the client does not know when you want to mark them read

what if you switch to the conversation, your unread marked message would become again read

As I say, I think (for me), reminders obviates the need for marking things as unread, at least most of the time.

usually clients mark something read, as soon as its displayed on the screen, which is not what you want with reminders

yes Kev, i support your point, read state is a poor man reminder

and insufficient for the task

i really like the idea, its also pretty easy to implement, a pubsub node, and a bit of UI magic

I think the sensible UI is the harder part than the protocol :)

i would go with Andrzej idea, as soon as you have set a reminder, there is some UI element that displays the list and messages of all your reminders, like a ToDo list in issue trackers, of course if you click on it you can jump to the conversation to get maybe context

that sounds like a nice idea

Well, and presumably showing some sort of notification and unread-ish marker when the reminder time arrives.

thats the question if needed, i would show a button with the count of reminders at all time

so everytime you look at the application, you know, there is still something todo

not sure if i would implement that "remind me in X hours thing"

"read state is a poor man reminder". Maybe we can accept read state is just a different use-case?

I think "remind in" could be an option

reminder sucks

(for my workflow, it may work for yours)

things reminders do which unread does not: - need me to think about when I'll have time for this - pull me out of focus when they trigger at a bad time because I misjudged the first thing

^

so those are orthogonal use-cases

These UX discussions are better made by users with the developers, it does not hurt to add the option to set a time to the pubsub item

personally i would also not do the alarm thingy from the start

more treat it like a todo list

"remind me in X" doesn't need to result in alarm, it could, but it could just mark some items as "overdue/need action" and just display badge in the client UI

Presumably it can use a similar badge to 'unread', if the unread badge is not distracting to you.

Yeah, I use Gmail's "snooze" feature quite a bit, which may be related

Are you inventing email?

Same effect, I think, yes Matthew.

That's more because I deal with a lot of email and stuff can get buried, but "snooze" will bump something to the top of my inbox at a time I'll be able to deal with it

I can't actually imagine doing that in IM, because I don't have enough new chats opening daily in that context for stuff to get truly buried, a "mark unread" would suffice

And I suspect that's the difference between the two

I somewhat frequently get messages in IM that I have to deal with, but can't deal with yet, and use reminder for that.

By far the most common is when a message comes in towards the end of the work day that I want to deal with in the morning, followed by a personal message coming in during the work day that I want to deal with out of hours.

Similar for me, if work stuff comes in out of hours and I'm on my phone and need to reply from my laptop, I'll snooze it until a time I'll be at my laptop

Instead of "actively remind me" it could be "bookmark this, put it on a to-do list I'll handle later, optionally remind me"

The protocol is probably the same, the UI is a bit different

"Reminder" can be associated with alarms/notifications/etc. but I think in this case it's more like a nudge that is usually wanted - a silent notification at most

For me, I'd like my client to treat them as it would a new direct message, I think, with the same notifications that would have. But I can see merit in having them without a time associated so they're in the list immediately.

> Is anyone aware of XMPP clients that do either 'mark unread' or 'remind me about this message in X long'? shameless plug... I did write this https://xmpp.org/extensions/xep-0435.html back then... Never got past a prosody module https://hg.prosody.im/prosody-modules/file/tip/mod_reminders, with no client implementation that I know of. It was thought as reminders à la slack, as told before. Main usecase was the one MattJ said: you catch a message in your cellphone while out of job already and don't want to miss it tomorrow morning.

yes great, but i see no reason why this should be depending on some reminder module on a server, store the information in pubsub. Further clients can read a clock themself, no need for a server to send a message

It does seem like PIP is perfectly adequate (and preferable) for this.

I'd definitely use bookmarks

Bookmark extension for ... unread?

That wouldn’t work for 1:1 chats though?

Don't we already have 333 for that, which works in MUC, even public ones .. awkwardly.

333 Doesn't allow syncing read state without leaking that to everyone else

The Tigase folks apparently do it with MUC PMs to oneself.

Maybe we still don't need to go through MUC for that

I don't think I want unread. I'd want an ability to pick a message that's bookmarked for later reference.

I haven’t read the whole discussion, but I saw talks of ‘remind me later’/‘mark as unread’ passing by today which 333 does not cover at all. I don’t have ideas as to how it should be done, but I sure think it would be a feature I’d use. Usually I just leave messages as unread from my phone when I plan on replying later (usually when I’m on a real keyboard), but it’s not excellent.

Unread is disingenuous. I did read it. It's a method from email to use unread as a proxy for to-do or similar. That doesn't feel like it'd work well for streams of messages to mark 1 of them as unread.

If it's just a note/reference to yourself then sure, some private PEP thing makes sense.

> Maybe we still don't need to go through MUC for that The tigase folks approach has the drawback of requiring the MUC to allow PMs and some don’t (and yes, gateways are examples of that, AFAIK semianon groups with group-mediated PM is more or less an XMPP-exclusive feature ^^)

Fishbowler: it works very well for me in rocket.chat

your argument is invalidated by practical experience

nicoco, yeah had to fix the anti-PM module when it was deployed here :)

Jonas’ and does the other party see that you’ve read the message or not? Also, why aren’t you the author of slidge-rocketchat already? 😉

I do agree the terminology doesn't make much sense when it comes to "unread", but usage is ok

Invent a way to bookmark stanzas, use that later for topic / pinned messages in MIX :)

nicoco: (a) they don't see either because that is not a thing, (b) I'm not going to invest private time for workstuff

I gather from Slack that you're supposed to use reactions for "I read this and had nothing useful to say so I reacted with 🦆️ or something"

(a) Oh I see, same as mattermost then (b) work? yuck! Didn’t AI free us of this yet?

nicoco, no AI freed us from the fun stuff like making art and music

https://xkcd.com/2565/ where one end is an AI thing, this is the future :)

You’re kidding about reactions but acking messages is actually a great use case for reactions IMHO. Not a single messager I know is 100% reliable when it comes to read markers, because it has to rely on focus, which sometimes does not mean you’re actually behind the device where the chat is focused.

nicoco: well did you think I'd use anything but XMPP for non-work stuff? :P

nicoco: yep, reactions are great for that

Of course, AI/webcam could be a thing for actually reliable read marks but HELL NO.

I doubt that

sometimes I read messages and immediately drop them out of my memory. are those "read"? :)

AI/brain-connected device it is then.

(but this is going off-topic)

see and so we need mark unread again

for when I forget and the brain interface notices

Btw 333 specs a way to acknowledge message, wasn't there agreement to drop that part?

I don’t know but I haven’t seen a single implementation of this marker, is there any out there?

and the part that overlaps with 184 and 198

> If the sender determines that the recipient's client does not support the Chat Markers protocol then it SHOULD NOT send Chat Markers or markable messages. I think that this part is not great either, because (a) the contact might have other devices that might support them, and (b) until we have a better XEP for read status, I actually want my markers sent anyway, so my other devices know that I’ve read the message(s). Maybe there is a justification for this that I am missing?

Am I reading our repo correctly that it doesn't require yearly updates to software entries anymore, to keep them on the website? ✏

iirc the main point of updating every year was to drop unmaintained software. Nowadays unmaintained software just don't have a doap file :x

Tobi, that was the idea, yes

So relying on the hosted-doap folder would be a bad idea?

Yeah, the yearly update got replaced by DOAP

The idea being that you need to keep up with the compliance suite, not keep some timestamp within one year

Ahh. I see. Ta.

DOAP can carry latest release info, dunno if anyone does that. Could also be something to factor into something, but on the other hand that doesn't really mean much.

poezio / slix do that yeah