Add `migrate` extension by aji · Pull Request #330 · ircv3/ircv3-specifications

aji · 2017-11-13T06:35:56Z

I'm working on an implementation over at https://github.com/aji/charybdis-migrate (No code yet. The code is all on my hard disk and is half-written, but my approach is outlined in the document.)

I think migrate addresses a big gap in the IRC client-server protocol.

migrate is designed to be dead simple for clients to implement, at the expense of more complex server-side implementations, especially for s2s protocols like TS6 that have no central authority to coordinate something like this. The idea is that if it's easy for a client to implement, then more clients will implement it and server authors won't feel like their effort is wasted by implementing it.

I want to hear people's thoughts so I don't waste my own time putting together a proof-of-concept in charybdis-migrate.

DarthGandalf · 2017-11-13T07:57:45Z

extensions/migrate.md

+appropriate client cooperation.
+
+Clients that support the migration protocol outlined in this document should
+register the `migrate` client capability. If the server supports client


It starts with server advertising it in CAP LS. The current text looks like it's tailored for clients which blindly request everything they support, without sending CAP LS

I can be more precise here.

DarthGandalf · 2017-11-13T08:04:48Z

extensions/migrate.md

+protocol are described later in this section.
+
+1. The server sends `MIGRATE START` to indicate that it wants to migrate the
+   client to a different server. Included in this message are a *resume token*


and address of the new server

Ah, I hadn't intended for this line to list everything in the message. I'll add a bit at the end that mentions the other fields.

DarthGandalf · 2017-11-13T08:08:45Z

extensions/migrate.md

+Other users in `#chan` will see messages 1 2 and 3 as if the client's connection
+was left untouched.
+
+## Client-initiated migrations


The previous text should have a title Server-initiated migrations

Well, "client-initiated migrations" are basically clients requesting that the server begin a server-initiated migration, and they're intended to be issued manually. I'll rephrase the title of this section to something like "Manually requesting a migration", or possibly omit it entirely. (Server authors will add appropriate additional commands for users and operators to trigger migrations so I'm not sure there's much value in specifying those commands.)

DarthGandalf · 2017-11-13T08:10:29Z

extensions/migrate.md

+    s1 <- PRIVMSG #chan :message 2
+    s1 <- MIGRATE OK abc
+    s1 -> :s1 MIGRATE PROCEED abc
+      (client disconnects from s1, connects to s2:6697 using TLS)


This doesn't allow client to connect to s2 first, and then disconnect from s1, which will result in some downtime. I don't know how important that is.

Hm, I'll have to think about the implications of that one. It should be fine but I want to give it some thought first.

DarthGandalf · 2017-11-13T08:16:26Z

extensions/migrate.md

+
+1. `REQUEST`, indicating the `MIGRATE REQUEST` operation
+
+2. The network-internal name of the server the client wishes to be migrated to.


Where to find such name?

This is the name in /map, /links, /whois, etc. The spec tries to distinguish between those names and DNS names, because there's not always a 1-1 mapping.

DarthGandalf · 2017-11-13T08:18:46Z

extensions/migrate.md

+1. `START`, identifying the command
+
+2. The client-reachable address of the server that the client will eventually be
+   migrated to. This can be either a domain name or an IP address, but should be


IP address in text format, I assume, not DCC format?

Yes, text format. I'll clarify.

progval · 2017-11-13T10:45:22Z

extensions/migrate.md

+2. The client confirms the migration request with `MIGRATE OK`. After sending
+   `MIGRATE OK` the client should stop sending normal IRC traffic, as it will
+   not be processed. If for some reason the client does not wish to migrate,
+   then the migration fails. After receiving `MIGRATE OK`, the server can begin


Should it reply explicitely it does not want to migrate? (eg. MIGRATE NAK)

I'm not sure how it would "fail" otherwise, other than that it just wouldn't happen and the server would keep waiting on it.

progval · 2017-11-13T10:46:03Z

extensions/migrate.md

+   client to a different server. Included in this message are a *resume token*
+   and *confirm token* that will be used when connecting to the new server.
+
+2. The client confirms the migration request with `MIGRATE OK`. After sending


What about MIGRATE ACK, to use the same vocabulary as the cap negotiation specs?

progval · 2017-11-13T10:47:41Z

extensions/migrate.md

+
+1. The server sends `MIGRATE START` to indicate that it wants to migrate the
+   client to a different server. Included in this message are a *resume token*
+   and *confirm token* that will be used when connecting to the new server.


You should specify the format of the message with these two tokens. I think it is rather clear what you mean, but since you are writing a specification, it is better to be explicit.

progval · 2017-11-13T10:50:05Z

extensions/migrate.md

+   the exact semantics of this message.
+
+5. The new server sends `MIGRATE CONFIRM`, containing this migration's confirm
+   token. If the confirm token does not match, the migration fails.


Could you state explicitely what "the migration fails" implies at this point?

progval · 2017-11-13T10:54:08Z

extensions/migrate.md

+   reachable by the client.
+
+3. The port that the client should use when connecting to the new server. An
+   ASCII plus character (`+`) before the port indicates that TLS should be used.


What happens if the old server uses STS, but does not use a + here?

progval · 2017-11-13T10:55:50Z

extensions/migrate.md

+    MIGRATE RESUME 5AEAD4D0
+    CAP LS
+    NICK aji
+    USER alex * * :Alex


This contradicts what you wrote above:

On connecting to the new server, instead of using the normal connection setup
protocol (NICK, CAP, etc.) the client sends a MIGRATE RESUME message

progval · 2017-11-13T10:56:37Z

extensions/migrate.md

+4. On connecting to the new server, instead of using the normal connection setup
+   protocol (`NICK`, `CAP`, etc.) the client sends a `MIGRATE RESUME` message
+   containing this migration's resume token. Refer to later documentation for
+   the exact semantics of this message.


Wouldn't it be required to do another capability negotiation, in case the new server does not support the same set of capabilities?

Additionally, could this instead use the "resume" spec (currently draft)? That might also make it easier on both clients implementing this protocol, and servers implementing "resume" if this is already implemented.

progval · 2017-11-13T10:59:10Z

This is a great idea and a good draft. As a client author, I really like how easy it will be for us to implement it.
Client-initiated is also a nice addition that could be useful in specific contexts.

jesopo · 2019-02-15T10:07:19Z

Huge +1 for this spec - seamlessly being able to push people off a leaf so it can be rebooted is a very cool idea.

That said, I really think this should be changed to leverage resume (#306) instead of having 2 systems that use "resume tokens" (that might mean that the wording for resume needs to change to "servers MUST allow cross-server resumption" - at least when combined with this spec.)

k4bek4be · 2021-08-23T19:58:00Z

This discussion looks dead for now. What about standarizing JUMPSERVER instead (or additionally)? It uses 010 RPL_REDIR as :irc.some.net 010 nick otherserver.some.net 6697 :Please use this Server/Port instead and looks like some clients and servers already support it. Won't be so seamless but easy on both sides. Only somehow make it aware about different kinds of connections (TLS, websocket etc).

Add migrate extension

552e219

DarthGandalf reviewed Nov 13, 2017

View reviewed changes

progval suggested changes Nov 13, 2017

View reviewed changes

DanielOaks mentioned this pull request Nov 6, 2018

Add resume extension #306

Closed

DanielOaks mentioned this pull request Jul 1, 2019

IRCX / MSN Chat - Pre 2000 was more advanced than you might think... ircv3/ircv3-ideas#48

Open

DanielOaks mentioned this pull request Mar 1, 2021

Update Registry wrt new PRs (esp fail/warn codes) ircv3/ircv3.github.io#356

Closed

10 tasks


		1. `REQUEST`, indicating the `MIGRATE REQUEST` operation

		2. The network-internal name of the server the client wishes to be migrated to.

Conversation

aji commented Nov 13, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

progval commented Nov 13, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jesopo commented Feb 15, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

k4bek4be commented Aug 23, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

progval commented Nov 13, 2017 •

edited

Loading

jesopo commented Feb 15, 2019 •

edited

Loading