Harvest chats

[mcfnord]

Maybe this is a controversial topic, but I want to monitor chat traffic to detect known link types like Jitsi or Zoom, or song links or titles. I could redirect journalctl -f -u jamulus-headless output to appear at an http address using nginx, which I could then monitor at a central location. At this time, I don't see chat entries in this log. Would I need to recompile to add this logging?

[ann0see]

The following is just my opinion.

Please don't. Chat messages aren't logged for privacy reasons. If the server admin does it - e.g. via JSON-RPC - they should state that in a privacy policy. Users shouldn't.

I think you have a reason for harvesting chats. Could you please state why - I assume that you'd like to have specific messages shown on your website? We should consider other ways to achieve that.

[mcfnord]

The website would show when there's an active Jitsi or Zoom video component. Or it might just notice a link to a song, and infer that they're playing that song. These links get shared in chat messages. If I see a link matching a known pattern, I would alert visitors that it exists. (By mentioning there's "Zoom Video" on that server.) If the Zoom activity is on the same server they are on, then Zoom Video would become clickable. I would discard the chats after examining them, so it's not logging so much as sifting. v1 will use a manual technique, where I can associate a link with a server until that jam ends. Won't be as cool. Still cool tho.

I guess it can have an opt-in like:

/share https://jit.si/foobar Description description

It would be better if the user doesn't need to learn a new syntax. So a chat daemon can detect a pattern and ask a participant to authorize sharing it. That would be pretty good.

If I could better alert people to servers that interest them by sifting through chats in real time for specific patterns, I would then deploy servers that do this, and invite others to do so. But I like this core idea of sifting and discarding on each server, and also like the idea of querying in chat to determine whether the fact of a link (maybe not the link itself) can be shared more broadly.

I plan to try the easiest thing, which is listening on my servers using gojam and centralizing to sift, because I'm impressed by the potential features inherent in the stream. I can process and discard the data immediately, and it would have TTL for its derivative forms in most cases. (I philosophically resist logging anything, but have accrued and plan features that have required that I log everyone's geolocation disclosures, everyone's duration with everyone else, the history of every public server jam, including everyone involved, start, and duration. Only recently have I begun logging names, which I've heard is controversial to some. Only some of this data is visible publicly, and that only reveals hashes. Now I guess it's hard to imagine what I'm not logging at this point... instrument? no, no skill level. I'm not logging that. Nor chat. But old chats don't seem useful at all, so it would be a purely live feature.) I was just thinking it'd be cleaner if the server disclosed chat without taking up a connection slot like gojam will. But ultimately the connection can take on meaning, as lobby has done. On such servers, users learn that a jitsi link gets thumbnailed on the website, and song titles may also appear there. This kind of data derived from links would also augment a live, localized newsletter by an LLM. So overall, if people share https links in chat, I'd consider each one in providing mostly real-time information to the larger community. I think I'm content with using a connection for these features. But I wondered what the server alone could produce. Of course it surfaces valuable participant metadata already.

[ann0see]

I mean that's all valid. I think the main issue is that server admins and user MUST know that this happens clearly - and there should be way to opt in/out and/or a private way to chat for more sensitive information.
We could rename the send button to "publish" or something.

[pljones]

Or have it as a split button

[Send | >]

with the > opening a drop-down with Send publicly or something, to highlight messages appropriate for reaping.

I pretty strongly think it should be opt in for each message on the sender's part.

[dtinth]

If it is your own server, you can apply this patch, which will expose additional JSON-RPC methods on the server-side that lets you monitor and inject chat messages.

dtinth@d846948

However, note that the patch has not been updated since Jamulus 3.8.2, since I now shift to build a userland solution over at gojam and jamulus-lounge instead.

[ann0see]

I believe the main issue is that we need to add some way for server admins to set policies/more metadata. Let it be hidden in the welcome message or in a jamulus message (e.g. serverinfo). This metadata would then be used for bots.