Zooko pointed out that we would benefit in the long run by adding some
extension-tolerance into the current release of foolscap. Specifically, there
are certain places in the FURL that could be extended in the future if we
were to make the next release ignore the extensions:
- tubid: allow use of other hash algorithms, by extending the definition of
the tubid field.
- for 0.2.6, we declare that we'll read the first 32 characters of the
tubid, assert that they are valid base32 characters, treat them as a
tubid, and ignore the rest of the string
- in the future, we can allow the tubid to be a comma-separated list of
tubid hashes, and we can declare a format like 'sha256d.abcdef' to
indicate the use of a different hash. When we actually start
implementing this, we need to be careful to not open up
protocol-rollback attacks or other vulneratibilities that result from
two different versions of the code interpreting the string differently.
In particular, the client should probably assert that all given
hashes match, rather than just a single one.
- during a transition period, host which wish their FURLs to be useable by
0.2.6 clients (and also want to provide better security for newer clients)
must make sure to put the undecorated sha1 hash first.
- connection hints: allow the use of other protocols, by adding elements to
the connection hints
- split the connection hints field on commas, then look for anything that
matches host:port, i.e. ^([^:]+):(\d+)$ . Ignore anything that
doesn't match this.
- I'd like to accept IPv6 addresses too, which means if the leading
character is [, then expect to see ]:(\d+)$ .
- In the future, we can add host:port:protocol, and trigger on the
presence of three colons. Or, we could do protocol:host:port, but that
is slightly harder to distinguish.
- Zooko is interested in alternative protocols with fewer roundtrips,
and possibly UDP based instead of TCP. For example, if the tub had an
ECDSA public key (perhaps instead of the tubid), then we could use a
":udp" protocol that encrypts the method name and arguments and
performs the entire request in a single roundtrip (with suitable
replay protection, which might require the maintenance of some local
persistent state).
In general, I'm not completely convinced that useful changes can be made
within the limits that we establish on the format now, but from what I can
tell we don't lose or risk anything by making these changes now.
