XSF Discussion - 2023-06-30

Hi, first search result on duckduckgo for "XMPP client" is the old list (curiously named "new"): https://new.xmpp.org/software/clients.html, and once you are there, all links stay there. Is there any reason to keep it, and would not is be better to redirect it the new website (the one without "new" in the URL :) ) ? And BTW thanks to the people involved, it's really neat (and I really need to do this DOAP thing).

TIL about new.xmpp.org Surely this should be redirected goffi: ping me if you need help re DOAP :)

cal0pteryx: thank you, but I mostly need time :). I have most of data already set in the code, I need to make a script to generate automatically the DOAP file.

I'll open a ticket for that

(the xmpp.org redirection)

No, I already posted it in infrastructure@

oh, so an issue is not needed?

right, thanks

Fixed

Confirmed that searching on DDG and clicking that link now takes you to the right place

Thanks for noticing :)

great, thanks MattJ

RSS/Atom have `<email>` but not `</xmpp>` does it :\

https://datatracker.ietf.org/doc/html/rfc4287#section-3.2.2 `<uri>xmpp:trung@example.net</uri>` ought to be fine

oh is that legal? cool (abit messy but ok)

Mentally rewrite <email> to <uri>mailto: ;)

😁

edhelas: could XEP-0469: Bookmark Pinning be used for individual contacts? I feel that it would make sense to use it for important contacts so they appear first.

specially between different clients 😕

This XEP makes not much sense, i think this was recognized earlier ✏

lovetox: why?

exactly because of what you say

its written as an extension of the Bookmarks XEP

meaning it only applies to MUC Bookmarks

but every client that allows Pinning, allows Pinning Conversations, and not only MUCs

Unified bookmarks + roster?

(time for?)

i would probably add a new pubsub node `xmpp:conversation:metadata:1` or something

and define there a <pinning>

and the item id = jid or somethng

wait PEP bookmark is only for chatrooms? I have not yes implementing it, and was assuming it was more general than that

roster in PEP? 🤣️

goffi, correct

I want to be able to bookmark pubsub nodes too.

Time for unified roster + group bookmarks + pubsub bookmarks!

its a storage to discover which MUCs you are joined, and what nick you use there, and nothing else

now that we have pubsub encryption, I'm thinking about having roster metadata on pubsub for a while actually (everything but the JID and presence subscription that are useful to server)

encrypted messaging over pubsub?

OK so now, how can I do pubsub bookmark, write yet another bookmark extension (this time it's *really* serious), or PEP Native Bookmark can be extended to handle pubsub items?

There's no reason bookmarks has to be used only for MUC. The spec does imply it's for group chats / chatrooms but is intentionally silent in what protocol the room speak IIRC

singpolyma: but it's a room, not a pubsub node.

I've been thinking to use pep vcard4 for extended roster data

goffi: what is a room? What is a pusbsub node?

These are just ideas

what is xmpp? am i even alive?

IIRC the original spec explicitly said bookmarks were for anything (allowing URLs, etc.), but this was hardly ever used in 20 years, and just complicates clients (most would probably choke on discovering a https:// or pubsub URI)

> what is xmpp? am i even alive? 😂️ ✏

I didn't know the newer spec narrowed the scope, but I think that was sensible

Rename it MUC Roster? :)

MattJ: yeah in the old time, but nowadays some clients are doing a bit more that chat.

there is an extension field though

and no attribute is mandatory

XMPP has been used for more than chat for a long time :)

Things have definitely put non-MUCs in bookmarks before

so beside the unadapted name `conference`, I guess that we can bookmark anything with extensions.

> Each item SHALL have, as item id, the Room JID of the chatroom

Right, it says that, but "chatroom" is explicitly not the same as "MUC" per the xep

It explicitely says that `<conference xmlns='urn:xmpp:bookmarks:1'/>` is valid

(not very useful though)

Yeah, extensions-only seems silly just use another pep node in sun a case imo

I think the spec is written not do require muc in order to allow for mix

But in practise that means one ought to be prepared to find things which are not a MUC and which one might not understand there

singpolyma: so you suggest an other bookmark XEP?

for anything but chat rooms?

why not Pubsub nodes?

we need more bookmark systems \o/

why do we need one node storage for *Everything*

goffi: no. I was just saying if you're adding things that are only extensions then that's a sign you're just making stuff up anyway. I'm fine to take a broad view on "chat room" and there's no real difference between a pubsub node and a MUC for most purposes. But it may depend what you want

lovetox, I agree

It's not the point of having a node for everything, it's to have a well-defined feature (bookmark here), with all we need (name, pinning, whatever), and usable for various use cases (MUC, MIX, single entities, pubsub nodes, etc).

otherwise, it's reinventing the wheel for a very similar feature.

the xep is about Groupchat Bookmarks

the XEP is named `PEP Native Bookmark` not `groupchat bookmark`

bookmarks* actually

yeah and ? as i posted before the item id must be a jid of a groupchat protocol entity

that makes it pretty clear for what this is

If we wanted it to be explicitly for other things we can edit that line

yeah, the use case was just not anticipated

Bookmarks only exist because roster implies presence subscription stuff you sometimes don't want

Otherwise we'd use roster

this is already a stable XEP implemented by many clients

you would need to show some real gain from adding stuff to this XEP that had nothing to do with its initial state

Bookmarks2? Are there many clients implementing? I thought only 2 or 3

i would say this will be very hard, and its much easier to simply write a new XEP with your use case

oh right I've missed the "stable" thing, great. So I guess the way to go is yet another XEP.

Stable doesn't mean final :P

and just my opinion, its very hard to write XEPs for future use cases which you cannot define, have no examples for

especially my experience with XEPs in XMPP is

the more narrow they are, the easier you get them implemented and used

For sure. A XEP should only be written after there is experience with deployed implemention IMO

Haha.

Write the code or the spec first, the age old question :)

Why not both? But write the spec on your wiki until the code is ready

That's what Experimental is for, I would think

so to answer my initial question, XEP-0469: Bookmark Pinning can't be used for individual entities due to the use of XEP-0402

For after you've got at least one implementation but not two or three yet I guess

goffi: can't is strong. But if you do Weird Things™ may happen in some clients

New pep node just to list pinned things?

new XEP to handle bookmark like use case for single entities, pubsub nodes, URLs, or whatever with pinning built-in.

Call it Roster 3.0 (now with bookmarks!)

and explicitely exclude group chat to redirect to 402 avoid more mess with that.

+and

how many things do you really have to bookmark?

goffi: for individual entities vcard4 xep is also a good choice imo

sounded to me you just want to bookmark pubsub ndoes

I want to pin inididual entities, bookmark pubsub nodes, and may need other stuff in the futur.

for instance, I need to know which calendar events I'm following.

Oh right. I now realize why were talking about pubsub nodes. They don't have JIDs

I forgot that for this whole conversation

> edhelas: could XEP-0469: Bookmark Pinning be used for individual contacts? I feel that it would make sense to use it for important contacts so they appear first. I guess so :) ↺

Can you bookmark contacts ? 🤔

edhelas: no-ish see above

I'm suggesting use some vcard4 property for this

I need to look at vcard4 spec to make a more concrete suggestion but I think there is a priority and if not there is definitely category

Wouldn't surprise me if the vcard* spec has some 'favorite' property ✏

singpolyma: they do have a JID, but it is associated with a node.

goffi: the pubsub service has a jidz and then that + node is the node. But you can't write the node are part of a JID only an xmpp uri

Zash: right. I have to look

singpolyma: indeed

Does anything do https://xmpp.org/extensions/xep-0292.html#contacts yet?

it may make more sense to use several node as mentioned above, otherwise it may be inefficient to filter if we have a high number of things to bookmark.

Zash: that's the vcard4 xep? I think no but I'm adding it soon ✏

singpolyma, the part of the vcard4 xep about storing contacts details

Zash: yes. That's what I meant

no lets load everything into one node, i love to download stuff i never need on every connect

lovetox: pubsub is made to not download the whole stuff each time.

Yeah how would that work for bookmarks?

How do I get only items which changed while I was offline ?