PRIVMSG server->client "from self" about ircv3-specifications HOT 11 CLOSED

👍

from ircv3-specifications.

This should probably be taken on board in some form, even if there isn't a cap for it. Plus ircds that support remote echo can use this to avoid having to alter the message.

from ircv3-specifications.

An initial specification is here.

Let me know what you think about the optional message tag that would allow clients to differentiate between the sessions.

from ircv3-specifications.

The optional message tag looks interesting… But it's not really user-friendly. E.g. you can't name the session "My spouse's laptop", or add some picture to it. Though that may be an ID of some record in metadata announced by that client earlier.
Also it's unclear whether the tag should be added to EVERY messages, even if they are coming from other people.
What exactly do you mean by "If the message tags capability is negotiated"? Message-tags is not a capability which may be negotiated… It's implicitly enabled when any capability which uses this mechanism is enabled.

from ircv3-specifications.

I'm trying to understand the purpose of this tag – is it similar to XMPP instances?

(Also, if it occurs frequently, should be a little shorter... maybe just session? One letter tags aren't really clear, but on the other hand, 512 bytes doesn't take long to fill up.)

from ircv3-specifications.

@grawity The tag is similar in intent to the resource part of a JID, yes: To indicate the specific connection that sent a message. The rest of the proposal is similar in intent to XEP-280.

@DarthGandalf I guess you could use the metadata stuff to do that. Use subkeys of user.session.<sessionid> or something.

Either way, it's unclear which messages should have @session. Probably not PRIVMSG from other people, certainly. The only uses I can think of that aren't presence require being able to send to a particular session as well.

from ircv3-specifications.

@kythyria yeah, “or something”... If it's really subkeys of metadata, it needs to be described in the spec.

from ircv3-specifications.

A better name for "session" is "origin", and my idea was that the bouncer could relay it along with
the message to the other attached clients to let them know which device sent the message.

Also it's unclear whether the tag should be added to EVERY messages, even if they are coming from other people.

No, I only thought of using it internally, i.e. only attached to the messages that have been sent by you on an other device.

What exactly do you mean by "If the message tags capability is negotiated"? Message-tags is not a capability which may be negotiated… It's implicitly enabled when any capability which uses this mechanism is enabled.

Yeah, this would require an explicit negotiation for message tags if we don't want to force it on clients.

I do not insist on this at all, if we can't think of a good use case for this then let's drop it.

from ircv3-specifications.

After some discussion, I updated the specification draft to only contain original idea.

from ircv3-specifications.

Since 2 months have elapsed I'm going to merge this in a few days unless someone has objections or suggestions.

from ircv3-specifications.

Merged.

from ircv3-specifications.