jdev - 2019-09-08

hi all :) this might be a silly question... but I'm playing around with trying to write a component (or something to that effect). anyway, is there any guidance/suggestions on when something should be a component and when it should be client/bot?

trying to figure out how all this stuff sorta fits together

allie, as a matter of fact i did write something on that: https://github.com/xmpp-docs/simple-muc-component-java/blob/master/README.md

the rest of the tutorial isn’t done. but the client vs component section is

How would I know I've received a directed presence from someone?

I start receiving presences from somebody not in my roster? that's it?

when do I stop receiving directed presences? What does the sender need to do? Send an unavailable presence?

yes

ok

hm but i dont know what the server actually does

if i send a directed presence, does the server then route all my status changes to that contact from that moment on?

I guess so?

or is it like i have to take myself care of all directed presences

but what if i send a contact a different show/status then my other contacts

this is totally a use case

maybe Zash knows ^

You get to do presence broadcasts manually for directed presence.

Ah

hmm so there's less privacy issues than I thought ✏

I thought the server would actually forward all my status changes etc.

yeah what i thought, everything else would not work

one of the usecases for directed presence is, that i can show a different status/show to a contact

so this would no fly if the server just broadcasts all my status changes

For me here it's the PEP updates use-case. I'm trying to come up with an update on that thread

i didnt really get that, you want notifications from a contact not in your roster?

https://mail.jabber.org/pipermail/standards/2019-August/036367.html that's the thread, and yes

I'd want to allow people who can see my presence after me sending a directed presence, receive PEP updates for nodes they've expressed an interest for (+notify), for items with access_model=open

Hmm, that means I also need to have the other side's presence though no? :/

To get the caps

not you

the server

and he can always query the contact if he needs to

Are caps available to anybody who asks?

yes

ugh

i mean depends on your client, a client could as well not answer a disco info request

You can ask a barejid no?

Or always fulljid?

i guess you can ask a barejid

but you will always get a answer from a fulljid

in the contact case

You'll get an answer from a random fulljid?

no you cant get an answer from a fulljid

> lovetox> but you will always get a answer from a fulljid

server will always add a from with a resource

ah sorry

thought about barejid

yes probably from all fulljids currently online

or do IQs to contacts always need to be to fulljid?

i dont know the routing rules

where does a server route a IQ with no resource

could be he doesnt at all

Ok that'd be what I expect I guess. Bob sends directed presence to Alice, requests Alice's caps on the barejid, it happens one of Alice's devices has foo+notify, and Bob has a foo node with open items

So Bob's server pushes that to Alice

Zash ^

but pep. i think you get yourself in a very complex situation that will not work good all the time

its easier to just add the contact to your roster

Yeah that won't happen :x

Not for me at least

so how long do you send directed presences?

say you have a convo with a contact not in your roster

you do your presence thing

now you restart your client, what now?

Yeah, read the thread on standards, that's also one of my questions

again sending directed presence? for how long goes that on? until the end of time?

the end of the session

Sure, probably

Daniel why though? one can argue that the chances of a device switch within a session is near zero

you dont need notifications for that

Except when it's not

And then you get users complaining

yeah sure, getting notifications only until you restart your client once, sounds like its surley work fine

As I don't add people in my roster that easily I suspect it'll be the case for me as well

what you need is a local roster

local roster of contacts which are not in your server roster

pep., but why are you fine with having your client (automatically) send directed presence for all open conversations but not simply asking for mutual presence sub?

then you can delete a contact from your local roster once you dont need him anymore, and can stop the presence thing

Daniel: it's not permanent right?

I can close the tab and be done with it

if privacy is a concern (which i get but might not share) subbing to pep seems like the only option

yeah why send directed presence, and not just sub to the node?

those subscriptions you could track and manage

Not sure yet.

lovetox: tracking-wise it's the same

I need to know when to unsubscribe, same as I need to know when to send unavailable

as i suggested make something like a local roster

Sure, that's an implementation detail

then you know for all contacts in that local roster you can do X

like sub on start of the session

or send directed presence

but you thought that only through into one direction

if you want to send messages

but the other way around will break easily

only if you send someone your presence, it does not mean he gets updates when you change your devices

or does it Oo?

When to subscribe is fine I guess. When to unsubscribe is a bit more annoying but also doable. When tab closes, on disconnect, and later when seeing a foreign PEP update

no i dont think so

No it's not a thing ✏

I was going to maybe change that in PEP, just trying to see if it's worth it or not

still see no benefit in this solution, i just add a contact to my roster and delete him if i dont want to talk anymore

thats 2 clicks

and zero implementation work

It's a bit less of a bother for a client to just send a directed presence I guess

Sure you still have to track who you're sending to

And you go through roster subscription flow and that's quite a pain for the user

no you are trying to implement a solution that will not work 100% of the time, and needs code changes in your client, and i heard no gain sofar

then make the roster subscription flow easier? actually it should just be one click

there is no need to bother the user with more

So much text

Then you need to go to your roster when you're done and delete it :x

lovetox [13:14]: > i guess you can ask a barejid you can't

Brb

That's annoying

i mean both managing directed presence and managing pep subscription seem like a pain in the ass

however one of those is available now without changes to the XEP

and to servers

pep. then add something so its not annyoing

like a button "Add contact temporary to roster"

which means the client will delete it automatically from the roster after X days

or at the start of the next session

seems much nicer to go the direction of automating this adding/deleting roster stuff

well there is also an alternate universe where roster means 'open conversations' (and not phone book)

that then would also act as a way to sync 'open conversations'

and you wouldn’t publish you entire 'address book' to the server but only 'open conversations'

so if you close a tab you remove that person from the roster

When do we finish that inbox xep

Ok so.. conclusion, we manually subscribe to PEP and that's it?

lovetox: never touch my roster without asking me. It's *my* roster, not yours.

pep.: BTW, how do you synchronize that state between multiple clients?

You don't? Every client does its own magic :/

Not that I wouldn't like to have that

That's an interesting question though

If only we had account side pep subscription management

the second half of my Quicksy talk was about all that

nobody cared back then :-)

Alice receives a message from Bob (who isn't in her roster) on her mobile and her desktop at the same time. She sees the message on the desktop but closes the tab and takes the discussion on the mobile because she's moving.

What do I do now.. One device will probably unsubscribe PEP, the other still needs it

https://github.com/iNPUTmice/talks/blob/master/2018_11_14_-_the_making_of_a_new_feature.md#to-roster-or-not-to-roster

i mentioning that because i already went to the thought process

Daniel, with multiple devices I'll have the same issue as bookmarks though..

I don't have the same usage of my phone and poezio :/

And then it's useless again

true

Unless the XEP has profiles etc., but I doubt we'll go that way

Also if you use that XEP with a device and then you forget about it, you'll be subscribed to all the open discussions for eternity :p

(with profiles)

Currently, if we choose to subscribe to PEP manually, I see easy fails with multiple devices as I mentioned above

One will subscribe, you'll receive a notification, another one will unsubscribe because they don't know who that's coming from, etc.

you can probably sub with your full jid to avoid that

hmm

That's handled by your server then? Or do all these queries get to the recipient's server?

but also direct sub will only nofiy you when the change occurs while you are online

(As in your server subscribes for you with your barejid, and only sends to the subscribed fulljib)

True

or we put that in MAM :-)

:/

What don't we put in MAM nowadays

MUC.

Only speak for yourself

I want to say <presence/> :-°

Chat states in presence?

Chat states make up a frighteningly big part of my MAM download

What

I remember that being the case, so I made mod_mam strip them by default (+ configurable whatever namespaces)

Zash: also empty messages from jitsi that only contain a thread

Zash: I'll run another sync job and give you the Smack class names of the elements in body-less messages

Ge0rG: Does it send it like that?

thread + chat-state I can believe, but only thread? wut

Zash: all I have is MAM

Somebody broke the xml log in poezio, and android hardly remembers the last half an hour

Ge0rG, it's back on master

For 2 weeks now

pep.: that's less than my poezio uptime.

Since we fixed the memory leak, there are no excuses left for restarting. Okay, actually there's one left, when my ISP fails and then the automatic reconnect fails as well.

Why are there carbons in my archive?

35% of all xmlns attributes are chat states

Zash: reduce your carbon footprint!

As opposed to Carbons, MAM won't tell you if a message is outgoing or incoming. This is a real consistency problem with self messaging.

but https://hg.prosody.im/trunk/rev/93a068ef4b2c

Most of them are from before that tho

Zash: how is this possibly a thing that a server operator would want to care about?

How am I supposed to know beforehand what should be archived and what shouldn't?

Read all the XEPs. Make informed decisions. Bitch on standards@.

And then things change again.

Zash: you can't have config variables for all the things that might change.

The list of plugins is the ultimate config variable for all things that will change.

And you have SCM for the code, with one central repository. Imagine thousands of server admins trying to keep up with the latest and greatest value for each config variable.

mod_mam_smart?

Actually it should just store everything and then do filtering when you query.

Please don't.

And whatever happened to chat states in presence?

It should do filtering based on the advertised client features, yes, but it really shouldn't store ephemeral junk like chat states

Zash: nothing yet

Zash: write the XEP!

My own server strips receipts, chat markers, hints, .... fight me.

Right, you don't need hint to store in MAM once they're in MAM. Shouldn't that be the default? :p

(not to store them)

Strip chat states. Realize archive is 90% chat markers. Strip those, etc.

Ask for 50 messages, get two with actual content.

Much fun.

Zash: receipts and markers actually make sense

Zash, do you also not store messages that are empty after you've stripped things?

pep., yes, that's how it knows there wasn't anything useful in them

k

And why a message with only a <thread> could make it in there, if it also had a chat state

Zash: why don't you store the unstripped version if the stripped one isn't empty?

Smaller storage footprint?

Less data to send when you query

Alright

Just that you might end up with only a thread element in MAM

And you shouldn't completely strip that out

What would you do do with a thread and a chat state?

You should have a smarter module and remove stuff that doesn't make sense anymore once you've processed all you wanted to remove :P

I should say patches welcome.

:)

post_post_process_messages

mod_aggregate_receipts_and_markers

mod_mam_plus

Isn't that the great plan already? MAM2

Not mam:2 right

No

MAM reimagined as some sort of multidimentional magic thing where each message has its own archive of addon-data

Yeah I know. Andrew Nenakhov even ranted about that on standards yesterday?

Hm? I'm referring to last Summit discussions

No wait, not an archive per message. An archive per extension per message.

Yeah, that was also discussed a few days ago in xsf@, alongside fastening

Also summaries of attached messages

<message type='chat' xml:lang='en' to='georg@yax.im/yaxim' id='7c0c163405834bfdb605eaf09333caa3' from='poezio@muc.poez.io/occupant'><origin-id id='7c0c163405834bfdb605eaf09333caa3' xmlns='urn:xmpp:sid:0'/><x xmlns='http://jabber.org/protocol/muc#user'/></message>

Zash: I end up with more worthless messages in MAM: ^

Zash: you can't strip <x/> or <origin-id/> from stored messages, but you can ignore them for the sake of storing messages.

Zash: so you need that split-logic after all

Doing other things and/or nothing today. Please open an issue and write down the requirements, without mixing in different issues.

Daniel: thanks for the link :) Although I'm still not 100% clear on when one should implement one or the other, unless the component is adding additional XEPpy features to the server. In those cases it seems it makes perfect sense. I guess it's a little confusing since, in the past, people have created components for things that didn't really need components.

I just want to write something that provides weather information to me and other users when requested. That seems like it'd be in bot territory, since it doesn't need to modify JIDs, isn't extending the server, etc.

allie: then write a bot

yeah prolly what I'll do

most of that was kinda thinking outloud :)

You make a component if you want to bridge to a different chat network

right, or I guess maybe pubsub-type stuff.

Ge0rG, that's not the only use-case, definitely.

You make a component if you need another addressing space(?) ✏

Is there a reason to do pubsub on a component instead of on a bot?

pep.: yes, that's the abstract way to say it. But where else do you actually need that?

I guess a component is also easier to bundle with the server usually

You could very well have a pubsub bot running on the server? :p

or like I was saying earlier if you're extending server functionality with another XEP

Ge0rG, though, a bot wouldn't appear in the server's disco#items would it?

Maybe not impossible to add it there.

I've been an xmpp user off and on for years. but never tried to make anything for it. so that's why I'm still feeling my way through the different parts, and if you're going by how others have implemented things, I guess they've sometimes implemented things in certain ways that may have been better in other ways

pep.: ask jonas’ if you really dare

:D

allie, sure some ways might be more appropriate than others :)

Ge0rG, just like you can have a MUC component on a barejid? :)

pep.: yes.

Aha, found the post I was reminded of: https://metajack.im/2008/08/04/thoughts-on-scalable-xmpp-bots/

So why would you make a component if you don't need the addressing space?

Can you call a component that doesn't make use of that space a bot?

You can call it whatever you want, it's all arbitrary anyways

I guess it's more that clients have lots of baggage that may not be appropriate for a component, whereas a component may as well be an entirely separate xmpp server that manages all its own stuff internally

Zash, not sure why the roster would be a problem at all. Just don't use it? :/

The component still needs to keep a mapping anyway

You can cheat if you do it yourself

Right

Also nothing says a component has to have only one role, right?

(That is, MUC, pubsub, user domain?!, etc.)

mod_pubsub could even be loaded on the vhost right?

Remember the special user@host component thing Prosody supports?

pep.: some client libraries seem to have very strong opinions on that

Ge0rG, open bugs!

pep., as long as they don't conflict in the namespaces and stuff they use. Eg disco gets funky sometimes.

pep.: BTDT

hmm right disco

I would have liked this <feature><feature/></feature> thing to happen :P

pep., but you're right, there's no problem with having pubsub and stuff on a normal host. MUC is problematic tho, since it overloads nodeparts

yeah

But I'm sure users and rooms can coexist. They can find a way to live in peace

Why can't users be rooms? And why can't rooms join users?

Such a philosophical question

Like DMUC (?) where MUCs join other MUCs and you get IRC-style trees

I was actually planning to look into that

That is, adding it on the TODO

A client needs different code paths for messages from a MUC vs from a user. You can't have both on the same bare JID

Zash: MUCs all the way down...

A room cannot be on a FullJid right? Otherwise there's no place for nicks anymore(?)

Correct