Added some i2p related address

[Jorropo]

You can find the description of how i2p address works here https://geti2p.net/en/docs/naming.
Bob, samX must be over udp or tcp address.
I think it can be used like that :
First listen on a i2p gateway :

/ip((4/<gateway ip, usually 127.0.0.1>)|(6/<gateway ip, usually ::1>))/((tcp)|(udp))/<port>/((bob)|(sam[1-3]))/<upstream hops 0-7>,<downstream hops 0-7>,<upstream tunnels 1-6>,<downstream tunnels 1-6>,<Upstream alterator -1 to 2>,<Downstream alterator -1 to 2>,([bds]|(both)|(datagrams)|(streaming))

There is 2 protocol, bob and sam, sam3 is the best of all (it have a lot of good idea of bob but multiplexed), bob is for more edge case and older version of sam are here if your node doesn't support newer one.

Upstream and Downstream hops is the number of relay to the rendez-vous (0 is a good choice if you are also serving on non anonymized network (0 disable anonymity but greatly improve speed, useful for providing an i2p to internet node), else 3 is a standard but this choice is yours) range is 0-7 (in i2p but maybe raise in future).
Tunnels count range is 1-6, limited by i2p can maybe be raised (with cpu performance at cost but higher multiple bandwidth), need test to about possible raising.
Upstream and Downstream alterator is of how many hops the tunnel must be randomly altered. All positive number are number of more hops added. So for 3 hops and 2 alteration the number of hops will be randomly between 3-5 (included) hops. For negative one that 2 directional, so 3 hops and -1 alterator the random will choose one between 2-4 (included) hops. This one is very limited is extremely dangerous if you do an error (but still proposed by i2p), also these kind of Multiaddrs will be encoded (and reprinted) as 2 hops and 2 alterator (which is totally the same).
Datagrams and Streaming are i2p version of udp and tcp, and that simply indicate if the bridge should listen on them (both or b for both, datagrams or b for udp like, streaming or s for tcp like).

The encoded version could looks like this :

varuint	varuint	varuint	varuint	3 bits	3 bits	1 bits	1 bits
Upstream hops	Downstream hops	Upstream tunnel count	Downstream tunnel count	Upstream alterator	Downstream alterator	Datagrams Flag	Streaming Flag

Alterator are 3 bits uint and need to be converted if -1 is putted.

And connection could be done for garlic* address reusing an instancied sam or bob transport (maybe with an integrated nodes in the future).

PS: I've discover after that alterator is a word not existing in english sorry. So here I use as the word alterateur in french (wich doesn't have an "official" validation but works in real life), this means the one that alter.

[ntninja]

Some thoughts/questions about this:

Alerators are 2 bits uint (-1 must be converted).

• Is -1 only allowed negative number for the up/down alternator? Could there ever be another negative/special value or is that implausible due to protocol constraints?
• May any of the positive-only values add negative special-cases like this in the future?

Upstream and Downstream hops is the number of relay to the rendez-vous (0 is a good choice if you are also serving on non anonymized network (0 disable anonymity but greatly improve speed, useful for providing an i2p to internet node), else 3 is a standard but this choice is yours) range is 0-84.
Tunnels count range is 1-6, limited by i2p can maybe be raised (with cpu performance at cost but higher multiple bandwidth), need test.

• For all the positive numbers you mentioned: Is there any chance of these values requiring more bits in the future (you already hinted at that with the tunnel count)? If “yes”, is there a strict upper bound on the number of bits they may require or could they potentially become arbitrarily large in the future?
  • If the answer to both of these question is anything other then “definitely not” for any of these values, then I'd strongly plead for for making the given values uvarints in the binary representation.
• Are any of the numbers optional?

There is 2 protocol, bob and sam, sam3 is the best of all (it have a lot of good idea of bob but multiplexed), bob is for more edge case and older version of sam are here if your node doesn't support newer one.

• Let me see if I can summarize this correctly:

  • bob and sam are two different and mutually incompatible protocols.
  • sam1, sam2 & sam3 are also different and mutually incompatible protocols.
  • All of these protocols use the same set of parameters.
  • When a node connects using, say, “sam3” to a node only supporting “sam2” the connection will fail and it will have to reconnect using another protocol such as “bob” or “sam2”. (The same being true between the “bob” and “sam” protocols.)
    • What I'm getting a here is that: There is no automatic version negotiation when two I2P nodes connect. One must already know which protocol the other node supports or the connection simply fail. (TLS for instance would automatically downgrade to an older version in this case if that is acceptable to both sides.)
    • If that is no the case we could simply have /i2p (or whatever) and leave figuring out the exact protocol used to the application.

• Bikeshed question: Are you proposing to separate these numbers by vertical bars in text representation? (I'd personally prefer something that is not a special character in shell scripts. How about using , instead?)

(Also there should be coma after the protocol name in the CSV for consistency.)

[Jorropo]

Is -1 only allowed negative number for the up/down alternator? Could there ever be another negative/special value or is that implausible due to protocol constraints?

Yes, -1 alterator is the only negative value possible, other or count of things and building -1 hops tunnel means nothing ? (except than not sending the message (but what about -2 so ?)), alterator is about how many the hops tunnel length can be randomly altered (so if you have an 3 hops long tunnel with -1 alterator you may end up with a 2, 3 or 4 tunnel long).

For all the positive numbers you mentioned: Is there any chance of these values requiring more bits in the future (you already hinted at that with the tunnel count)? If “yes”, is there a strict upper bound on the number of bits they may require or could they potentially become arbitrarily large in the future?

Yes I havn't even thinked to that (thx), so hops and tunnel count should be varuint.

All of these protocols use the same set of parameters.

Yes but in fact these parameters are not about the protocol but about what is next, in fact these protocols allows you to get a connection to i2p and the params are about this connection to i2p (number of hops, tunnel, ...), these protocols just need ip (or a resolved dns) and tcp or udp (udp is only for sam3 (and maybe sam 1 and 2, idk)).

What I'm getting a here is that: There is no automatic version negotiation when two I2P nodes connect.

Yes, bob and sam doesn't use the same port so this isn't possible to do auto negotiation but for sam you can simply try 3 if that doesn't works try 2 and if that doesn't works try 1.
The problem is the invert part, newer node of i2p not support latest version of sam so if a newer version of sam came out it wont be certain to be supported by default.

If that is no the case we could simply have /i2p (or whatever) and leave figuring out the exact protocol used to the application.

Good idea but not for bob and sam since they don't share the same port (and there is no bob over udp (if that was not implemented since the doc on it was made)) and I don't think /i2p is clear, I think people will mess it with /garlic because i2p use .i2p in url while multiaddr call it garlic32. But a sam could maybe do it.
BUT the problem is here for transport devlopers, there is a few library for sam 1 and 2 (or they wern't updated since a while so they will not works anymore), also there isn't any implementation that support all sam version (I'm sure of that for golang and js) so its even if that seems logic that isn't, because what if a sam4 or bob2 it would require to update your transport, so having them with an other name could be good for understanding why its not working any more ?

Bikeshed question: Are you proposing to separate these numbers by vertical bars in text representation? (I'd personally prefer something that is not a special character in shell scripts. How about using , instead?)

I pick that totaly randomly because it looks close to / but , could do it well.

[Jorropo]

While implementing I wondered that steaming or datagrams isn't specified in the garlic, so we need to specify them in an other way.
I've called i2p-* and not garlic-* because they are in the application layer of i2p, not routing or tunnel and so its possible to implement an i2p compatible node without them (that quite what is done by kovri).
Code could be discussed.

[Jorropo]

garlic should be enough