Groupchat 3.0 development - 2025-05-28

> How are you proposing to tie VR into GC3? That requires more information.

Let's see, the re-review of the context re-highlights the grave unfamiliarity of the local populace with the matter. The best simple way to describe is it can and fully is able to combine the nicest prettiest qualities of both virtual textual and the non-virtual, removing the downsides of both gracefully. One of the downsides is all of you seen and will see again forever how some do not act like they would've acted in the physical, so unconstrained, without grace, that's the consequence of the chat being textual, they don't feel you, to them you're none but a word on a screen: VR is able to address it, thanks to having a body, and give you and them the grace of dignity, resulting in a better environment for everybody involved in the matter.

> Not, please. Luddites said the same a long ago, it didn't end well for them. Without taking the lead of power and wisdom the more eager ones will draw the lines of the future that you'll have to obey: Want to live well, embrace and blaze with own path forward; Want to fail, be scared and run away, then bow and be devoured by the dragon.

Survival of the fittest.

I think first you should learn more about the historical luddites before makng such broad and false claims 😅

I do want more moderation features to appear in GC3 though..

What kind of moderation features?

Things like blocking another participant (maybe by occupant-id rather?), shadowban? voteban, etc.

also: - bans with a time limit - allow people to speak with a time limit - more gradual permission system granted this may be its own XEP anyways but still

Well the "more gradual permission system" may be accomplished by the ACL spec being worked on I guess (is it? being worked on though)

Bans and mutes with an automatic time limit so the moderator doesn't have to remember to unban would need server support for sure I see that. Might not need anything in a xep to accomplish it, but it's so closely related to something that *is* in the xep I could see it yeah

it needs protocol to signal to the server for how long an action should apply

Blocking other participants we have happening now under MUC and GC3 will make it slightly easier by mandating occupant id

Well basically everything that is generally implemented via a bot could be added to the protocol so that bots aren't required anymore

> it needs protocol to signal to the server for how long an action should apply Yes. But we have protocol to signal anything to the server we like with ad hoc commands 🙂 ↺

> Well basically everything that is generally implemented via a bot could be added to the protocol so that bots aren't required anymore Oh sure, I would never use a bot in a MUC for management etc things, that's usually due to using a public server that doesn't happen to run modules one wants as a workaround ↺

singpolyma, ad-hoc commands aren't WD40 ;)

hah

> singpolyma, ad-hoc commands aren't WD40 ;) No they're html/http ↺

exactly

(and that is not a good attribute for anything)

I mean if you don't like html I guess we just have to agree to disagree. Hypertext and UI malleability are core features for me

As a server dev, I have never thought "Thank goodness this uses adhocs, they're so much easier to deal with than specfic XML payloads". As a client dev I have never thought "Thank goodness that the thing I'm trying to write a nice UI for is using adhoc commands and I have to add layers of abstraction". They do have the advantage that legacy clients can still do the thing, after a fashion, but for everyone who wants to support a thing nicely they just make life harder.

wait so ad-hoc commands are just for legacy purposes? 🤔️

i thought they were more important for some reason

Kev summarized it nicely.

in a way, ad-hoc commands are more like html 0.9 or so

> wait so ad-hoc commands are just for legacy purposes? 🤔️ No ↺

But obviously there is disagreement

I'd rather have proper support in gc3 for what biboumi does than have to have ad-hoc commands for that, for example

Ad hoc commands allow a service to add features and get great native UI integrated into client apps without the apps needing to be specifically aware of the feature

While still allowing a client that *is* aware of the feature to do whatever it wants

ah so they are basically escape hatches for the future

(if the command is standardized or whatever)

Escape hatches sure or where you can put service specific stuff

FSVO "great native UI"

in most cases it's indeed better than nothing

Sure. If the app implementation of ad hoc sucks then the UI could be bad. But that's on the app dev

the problem is that for the cases where you *do* want to implement nice support, you are limited by the wire protocol of ad-hoc, which is ... not great.

I would've thought it would be easier because of code reuse in the client.

I mean, the wire protocol of adhoc is just "iq but there can be more than one"?

we could always just do XForms 🤷️ /s

MSavoritias (fae, ve): if you want xforms you can use them as an ad hoc payload. Though data forms is pretty fit for purpose with a few of the extension xeps I think

singpolyma, you lose the "escape hatch" if you do anything except '4 inside ad-hoc though.

Depending on what your clients support. But yes I always include at least one data form alongside my other payloads

what do you do when a client replies to all of those payloads differently?

How do you mean?