Need to fix/figure-out cross-realm zephyring

[dovej]

We have some issues with cross-realm zephyring. The canonical example is shadow/*/@ANDREW.CMU.EDU. There are two main problems:

1) We don't distinguish cross-realm zephyrs. So, shadow/*/@ANDREW.CMU.EDU is not distinguished from shadow/*/* (the ATHENA.MIT.EDU analogue.) This has the opportunity to cause a lot of confusion at face value, but fortunately, as far as I know, people are rarely subbed to the same class on two different realms. Nevertheless we should distinguish them. This opens a whole can of works with respect to narrowing.

2) When replying to a cross-realm zephyr, the recipient field should default to the proper realm. In our canonical example, the recipient field should default to "@ANDREW.CMU.EDU". The @ is important. Without defaulting the recipient in this way, replies will not actually make it to that class unless the recipient field is manually corrected.

(2) is more important that (1) in my opinion, and is fortunately easier.

[jrafidi]

Hm so based on my (very limited) knowledge of what you are talking about, (2) should already be complete. Ex: if I select a message sent from, say, rlink@CS.CMU.EDU, and I choose to send a private message, the message correctly has rlink@CS.CMU.EDU as the recipient. Is that what you mean?

Or do you mean that class/instance pairs have their own realms? That's totally news to me.

[dovej]

Nope, I do in fact mean that class/instance pairs have their own realms. For example, when you sub to my class, you are implicitly subbing to dove/*/@ATHENA.MIT.EDU. You don't need to specify the realm in the recipient field though because we are all on ATHENA and that is understood. But, dove/*/@ANDREW.CMU.EDU for example is a totally different class. We do have a few cross-realm classes that are marginally popular.

[davidben]

class/instance pairs are realmed. They're not pairs, but triples. A message to realm CS.CMU.EDU, class foo, instance bar has recipient @CS.CMU.EDU, class foo, and bar. The one special case is that your native realm has recipient empty string. So for an Athena deployment, whenever others would send to @ATHENA.MIT.EDU, you see and send to empty string.

[jrafidi]

I'm guessing this is information sent from the backend on the zephyr/subscription that I stupidly ignored because I had no idea what it was?

[jrafidi]

Or rather, had no idea it was possible.

[dovej]

Yea it's in the subs and the individual zephyrs. I would have been shocked if you noticed it though. There's no way you'd notice it unless you were subbed to a non-ATHENA class. It is definitely a quirk.

[davidben]

Yeah, the backend gives you the zephyr-level recipient for both messages and subscriptions. You'll need logic in the client to them extract whatever information about the realm you want from that. When the old client makes a filter, it never filters on a class without also including the recipient; thus class foo on two realms are treated as different. I think I add a new component to the message header if the realm isn't your native one to display it in the UI.

[jrafidi]

Alright cool. Can you suggest something I should sub to so that I can actually test this?

[dovej]

shadow/*/@ANDREW.CMU.EDU is the canonical example

[dovej]

Note that's a CMU person's personal class.

[davidben]

I'd probably recommend fiddling with ZONE.MIT.EDU. Then you won't be stomping on CMU's realm and stuff. ZONE's something SIPB-related I believe.

[dovej]

Yea, that's an option. I suppose you don't actually need anyone with a principle from the realm in question to test this, and you can generate your own traffic cross-realm. ZONE is in fact SIPB-relevant for this sort of thing.

[dovej]

So you can just play with roost/*/ZONE.MIT.EDU I suppose. Make sure to sub to it.