jdev - 2020-03-15

i can only think of a single one, which is already handled in dino. that is channel vs group

i cannot imagine a channel that has logs activated where it's not wanted

gotta run. thanks for your insights

some people mind their privacy

and good luck with 0.2

there is no privacy in a public room or work room

pretending you have control over it is lying to people

if I configure the room such that only people that have been in at least once can see the MAM history, I can gather a list of users that are able to read the messages I wrote

*at least once before a message

basically MAM being activated for a user the first time they join

and disabled as soon as they get banned

i don't see that as a wide issue with any other platform that has seamless history. and if you're banned you would likely not expect to get the history

the point is still that normal users and especially groups of users who use it for collaboration, expect seamless history, same as on all other group collab chat platforms. but i realize that dino perhaps isn't made for that, and that i'm abusing it

at least there's a comment on that wiki page now, so someone else like can find out about it being missing

this seems to be a lot of text written for something that's planned but just not done yet?

sry :)

someone's saying it's not important, and i'm trying to explain why i think it is. nuff said. laterz

and thanks for dino :)

:)

i do have an actual question that's more on topic though: default limit of participants in my rooms is 200, according to the room settings. does anyone have experience with a few thousand users in one room?

and is that limit for active online users only?

afaik in MIX, presence is persistent, so it works more like the collab chat apps i mentioned

just wondering if anyone has experience with groups at scale...

the limit is for currently online users

good to know

thx

and you can certainly have MUCs with several thousand of people in there, joining them may take some time on slow connections though

you mean receiving presence may take some time

from the other users

I think I've only seen IRC channels with participants in the thousands, and those were impossible to follow, anything said would be drowned in noise

I believe that humans don't easily scale to groups that size without very strict management.

most people in public channels just idle

and read

same as most people on twitter never post

yeah, I know these kind of rooms

i'm joined in some

technically, if you only plan to read, you could also just not join and only fetch MAM...

now that there's matrix bridges for a lot of irc channels, being are always joined

s/being/people

larma: that's bad for the project/group though. seeing presence of other people is important

yeah, I hate it when that happens, because the people on the bridge often don't understand they are bridged to an IRC channel and that some people are not online all the time and thus don't get all messages 😀

see gitter etc.

if they don't write, why is presence important?

to be fair, people who actually use irc usually also run a bouncer

raucao, true

it's important to see that a project/channel is not just 5 people, when there's a lot of interest

to gauge activity of the project overall

and success/interest

ah, but you could also solve that with just a number, you don't need a full blown member list

that's a ui detail

there's no reason not to have a member list

also mostly client implementation problem to solve

in terms of performance

well, the reason is that fetching 5000 members is a huge burden to clients

you don't need to re-fetch that all the time

I know for certain that Telegram does not fetch the full member list, they do fetch the member number and as soon as you open channel details they fetch members by last activity in pages (further loading while scrolling)

yeah, that's reasonable

caching offline is also reasonable

but that's kind of a completely different concept then what we typically do in XMPP 😉

you shouldn't get everything live all the time, when it's not necessary. it's not much data to store locally

I agree it would be great if we could get diffs on MUC join instead of the full list

just because existing clients have done it differently in the past is no good reason to not improve it in the future

You mean MIX?

though many people leave the room over night

MIX is more like Matrix room management: people never leave 😀

yes, that's preferable for collab channels imo

looking forward to MIX

diffs would also be cool

but you can easily fetch 1000 participants in the background, after fetching all the stuff that is more important

and in the meantime show the cached data

for participants

depends on your network

of course

I don't see you fetching 1000 participants just because on the 64k connection

you could still do it, as long as you cache the data, and you queue those requests after MAM ones, so they don't block actual chat usage/history ;)

TIL there is a MUC participant limit

I expected there were technical limits, I didn't know there was an actual implementation limit ✏

ejabberd?

k

i think in all that discussion you failed to make it clear that the "room options" as he thought, is the configuration of the MUC on the server itself and he only sees it because he is admin. It makes in no scenario sense to hide admin configuration options for a server only because the client the admin uses cant use that feature if its activated

thats like, oh your terminal is not an XMPP client, i guess you cant edit the XMPP Server configuration file :)

btw joining a IRC bridged channel

like #python with 2000+ users needs around 3-4 seconds

raucao: are you still in need of a wiki account?

lovetox, that's up to the client to make that bearable UX-wise I guess :)

I'm in #archlinux with about the same number of participants and it's just fine

I was fully aware of what the room options are. I even explained it back.

Still think that's bad UX wise. You assume room owners are always xmpp experts. I even know a lot about it and it got me

Ge0rG: yup

does anybody have a xmpp server

that does not allow IBR?

seems every server i test has it activated

ok xmpp.org

mdosch.de also doesn't have public ibr

but it announces it nevertheless in its stream features

Yeah, that's the snippet module. But you can only register with a valid token.

Or it's f'd up and i'll have a lot of spammers soon.

Martin, on request you return a register form

whats the snippet module?

is there docs somewhere

snikket?

or that

ok so what is snikket

seems like it forks conversation

please someone give me the gist im not getting it from the homepage

Friendly conversations and prosody fork

Kinda aimed at people who just want secure private self hosted chat and don't know or care what XMPP is

lovetox, client & server from the same brand, friends&family targeted, easy invitations

Ie normal people, not anyone here

yeah, that

ok and who does that project?

MattJ

I guess I helped some, and Daniel helped with the Conversations bits

ok so you can only register with a invite

yes

but snikket server are still federated i guess with all other servers

yes

ok and how does that token thing work protocol wise, is this somewhere specified?

XEP-0401

Or some version of it

probably "some version of it"

k thanks

possibly the one which is pending OK from the author

ok but how i read xep 401 it does not mandate that the ibr register namespace is announced in stream features

so Martin i dont think that has something to do with it

you should check your config and disable IBR if you really want it

lovetox: https://docs.modernxmpp.org/client/invites/

I think that's what's currently implemented

so that intentional?

why was <register xmlns='urn:xmpp:invite'/> not enough?

this thing has absolutely nothing to do with the IBR XEP so i dont really get why you reuse the namespace

there’s a lot of fun discussion around this

or is registration still possible with IBR

then its ok i guess

IIRC it uses IBR, but you need to provide the token first

if someone write a new registration XEP, i would really stay miles away from anything that touches IBR

> In the success case, the client proceeds with registration using e.g. XEP-0077 in the normal way.

like its complex enough, no need to add more on top

lovetox: it was designed this way exactly to detach it from IBR

After the preauth step you can use any protocol to create an account

Just that IBR is all we have right now

so if i use IBR directly i get a error

lovetox: > ok but how i read xep 401 it does not mandate that the ibr register namespace is announced in stream features > so Martin i dont think that has something to do with it > you should check your config and disable IBR if you really want it I had to enable register for it to work. But it should be impossible to register without an invite. As I don't see spam activity from my server I guess ibr is not wide open.

hm yeah i think i misunderstood how that works

MattJ, hm what happens if i disconnect after i sent the auth token, is it still valid on reconnect?

ok

yes, it says that in the docs

ok looks good, maybe i add this in Gajim soon, as i redo the account wizard right now

there is an example to register a specific username

but its not mentioned later how that works

lovetox: that's in the XEP, but basically you just have to use the username in the URI or you'll get an error when you try to register

I think it's in the XEP anyway, but a lot of what I thought was in the XEP later turned out not to be...

Anyway, if you implement it, let me know :)

MattJ a server to test against would be great with a view tokens if you have that available

I hear snikket is easy to install

If you're non-technical

yeah i guess i could install it on my own server

lovetox: can provide a dev server with an endless supply of tokens, but probably not today

yeah sometime next week would be great