jdev - 2023-01-03

hey, is the old GC1.0 protocol written up somewhere

today i feel like digging out skeletons

Why would you? :)

sometimes in life, there are moments where you just want to jump into a dumpster

I don't know if there's a clear picture of what GC1 was. 0045 has been improved over time and we're still removing piece of it that look like GC1 sometimes ✏

I don't think it was ever written up in XEP/JEP form, but there are definitely some rough docs around

It predates JEPs by some margin.

This is probably as good an overview as you'll get: http://archive.jabber.org/docs/jpg/#CH-GC

Ah well then it's before my time even

Kev, so do a number of protocols that were later written up as JEPs though

Yes, but in this case when the JEPs came, they tried to do better.

MattJ: this will do, many thanks

I think that just wasn't done with GC because it was still in flux and updates were included during the doc-writing

I think if you read earlyish versions of JEP-0045 one can infer groupchat 1.0 protocol from it.

""" This JEP must address the minimal functionality provided by existing multi-user chat services in Jabber. For the sake of backward-compatibility, this JEP uses the original "groupchat 1.0" protocol for this baseline functionality, with the result that: Messages sent within multi-user chat rooms are of a special type "groupchat". Each room is identified as room@service (e.g., jdev@conference.jabber.org), where "room" is the name of the room and "service" is the hostname at which the multi-user chat service is running. Each occupant in a room is identified as room@service/nick, where "nick" is the room nickname of the occupant as specified on entering the room or subsequently changed during the occupant's visit. A user enters a room (i.e., becomes an occupant) by sending presence to it. An occupant exits a room by sending presence of type "unavailable" to it. An occupant can change his or her room nickname and availability status within the room by sending updated presence information. The additional features and functionality addressed in this JEP include the following: "native" conversation logging (no bot required) enabling users to request membership in a room enabling occupants to view an occupant's full JID in a non-anonymous room enabling moderators to view an occupant's full JID in a semi-anonymous room allowing only moderators to change the room subject enabling moderators to kick participants and visitors from the room enabling moderators to grant and revoke voice (i.e., the privilege to speak) in a moderated room, and to manage the voice list enabling admins to grant and revoke moderator privileges, and to manage the moderator list enabling admins to ban users from the room, and to manage the ban list enabling admins to grant and revoke membership privileges, and to manage the member list for a members-only room enabling owners to limit the number of occupants enabling owners to specify other owners enabling owners to grant and revoke administrative privileges, and to manage the admin list enabling owners to destroy the room In addition, this JEP provides protocol elements for supporting the following room types: public or hidden persistent or temporary password-protected or unsecured members-only or open moderated or unmoderated non-anonymous or semi-anonymous """ etc.