25 Feb
2025
25 Feb
'25
10:55 a.m.
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Server-side spaces
Abstract:
This document defines an XMPP protocol to cluster several groupchat
rooms together.
URL: https://xmpp.org/extensions/inbox/spaces.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
4 Mar
4 Mar
11:54 a.m.
Le mardi 25 février 2025, 16:55:37 heure normale d’Europe centrale Daniel
Gultsch a écrit :
The XMPP Extensions Editor has received a proposal for
a new XEP.
Title: Server-side spaces
Abstract:
This document defines an XMPP protocol to cluster several groupchat
rooms together.
URL: https://xmpp.org/extensions/inbox/spaces.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
Hi,
Thanks Nicoco for your contribution.
For the record, I've voted +1 on it as I think that it's a very much needed
feature, and it's good to finally see some move here (where there was work
before, but not visible in the standard@ process).
I have a concern about using a trademark known for a conflict about its name in
example (Apple Records), but IANAL, maybe it's fine. We have also said in the
council meeting that making up TLDs is not a good idea either (even if it's
fun, they can be registered anytime), there is the `.example` for that.
My other concern is technical, I have the feeling that we are re-inventing
pubsub on top on disco here, with actually using pubsub for subscriptions, and
Ad-Hoc for creation/deletion (which are built-in pubsub features).
I'm known to be a strong pubsub advocate, but I really think that it's a
better fit here: all feature are here, with permission management, subscribers
list, etc. By using disco, we're have to reinvent the wheel IMO.
That's not a reason to block this specification, but that's something which
should be discussed to be sure we are going in the right direction.
Best,
Goffi
5 Mar
5 Mar
12:28 a.m.
Hi,
there was work before, but not visible in the
standard@ process
AFAIK there is Kev's
<https://github.com/swift/protoxeps/blob/master/related-entities.md> and
a pad that I cannot find anymore, but which attempted to cover ACL too
IIRC. It had not been active for a while, hence my attempt to revive
"spaces".
I have a concern about using a trademark known for a
conflict about its name in
example (Apple Records), but IANAL, maybe it's fine. We have also said in the
council meeting that making up TLDs is not a good idea either (even if it's
fun, they can be registered anytime), there is the `.example` for that.
Oh, I can
change that. I just happen to be extremely
Shakespeare-illiterate and didn't want it to show too much.
My other concern is technical, I have the feeling that
we are re-inventing
pubsub on top on disco here, with actually using pubsub for subscriptions, and
Ad-Hoc for creation/deletion (which are built-in pubsub features).
I am probably biased because of the clients I am using, but it seems to
me that generic adhoc command support is more widespread than generic
pubsub support. I suspect this is because XEP-0060 is huge and scary,
which is something I specifically did not want this XEP to be.
Maybe we could add pubsub's mechanisms for creation/deletion too? Did
you have XEP-0248 (PubSub Collection Nodes) in mind too?
Anyway thanks a lot for the feedback!
Cheers,
-- nicoco
4:23 a.m.
Hi,
Le mercredi 5 mars 2025, 06:28:32 heure normale d’Europe centrale Nicolas
Cedilnik a écrit :
You did good, things need to move on this feature.
Yeah that's not a problem, no need to use Shakespearian characters all the
time, many XEPs don't.
Most clients do because it's necessary to use things such as OMEMO, modern
bookmarks or VCard, etc. No need for a full XEP-0060 implementation.
there was work
before, but not visible in the standard@ process
AFAIK there is Kev's
<https://github.com/swift/protoxeps/blob/master/related-entities.md> and
a pad that I cannot find anymore, but which attempted to cover ACL too
IIRC. It had not been active for a while, hence my attempt to revive
"spaces". > I have a concern about using a trademark known
for a conflict about its
name in
> example (Apple Records), but IANAL, maybe
it's fine. We have also said in
the
> council meeting that making up TLDs is not a good
idea either (even if
it's
fun, they can
be registered anytime), there is the `.example` for that.
Oh, I can change that. I
just happen to be extremely
Shakespeare-illiterate and didn't want it to show too much. > My other concern is technical, I have the feeling
that we are re-inventing
> pubsub on top on disco here, with actually using pubsub for subscriptions,
and
Ad-Hoc for
creation/deletion (which are built-in pubsub features).
I am probably biased because of the clients I am using, but it seems to
me that generic adhoc command support is more widespread than generic
pubsub support. I suspect this is because XEP-0060 is huge and scary,
which is something I specifically did not want this XEP to be. Maybe we could add pubsub's mechanisms for
creation/deletion too? Did
you have XEP-0248 (PubSub Collection Nodes) in mind too?
I'm thinking about vanilla pubsub, the same mechanism as used now, just on
pubsub nodes, that gives out of the box subscriptions and permissions
management.
Pubsub Colleciton has nearly no implementation, and has some issues. I've
actually proposed an alternative with XEP-0496 "Pubsub Node Relationships" and
following XEPs, but it's too young and there is not yet implementations. I
think vanilla pubsub is enough for the moment, this can still be used later if
the need arises.
Note that this is just a suggestion. Your specification has been accepted
anyway.
Anyway thanks a lot for the feedback!
Thanks for your specification and work in general :)
Cheers,
-- nicoco
Best,
Goffi
29
days inactive
37
days old
3 comments
3 participants
participants (3)
-
Daniel Gultsch -
Goffi -
Nicolas Cedilnik