Hello Zach,
Zack Weinberg wrote:
The present netsync protocol uses a cryptographic primitive (RSA
decryption) that isn't supported by ssh-agent.¹ This is why you get
prompted for your passphrase on 'mtn sync' even if your key is already
loaded into the agent.
In implementing the new network protocol, please consider making the
crypto handshake require *only* RSA/DSA signatures, as that is the
only primitive that seems to be universally supported by ssh-agent.
I'm not sure how to do that, but evidently ssh itself does, so it must
be possible.
Thank you for this note. I'm not exactly a crypto expert, so that's very
helpful.
However, ATM nvm.nuskool is pretty simplistic and works over HTTP
exclusively, ignoring any branch patterns and synchronizing all
revisions in the database.
I'd like to go for something more RESTful, as far as the HTTP interface
is concerned. This should make better use of the HTTP caching
infrastructure and would probably even allow something like the "mtn
dumb" server interface.
If we still need olskool netsync (do we?), we should encapsulate the
communication channel stuff from the nuskool new DAG based refinement
thingie, very much like the current refiner is separate.
What I'm pretty dubious about HTTP/JSON with regard to binary data. On
[1] they say, that JSON strings allow all Unicode characters, with some
exceptions, which can be hex encoded. But writing out valid Unicode from
binary data seems troublesome to me. And for the format to be really
useful from browsers and such, we'd certainly want to make the format
standard compliant. So via HTTP, we are probably going to send around
hex or base64 encoded data.
Covering all use cases I can currently think of would lead to three,
slightly different refiner procedures:
1.) sync from mtn client to dumb http server with static files
2.) sync from mtn client to clever http server via scgi to mtn server
3.) sync from mtn client to clever mtn server via netsync
While the first two require a state-less approach, fitting HTTP, the
third option doesn't. I'm not sure if it's worth exploiting that.
Probably not. And the first option is quite different in that we cannot
put any logic into the server, for obvious reasons.
Still quite a long way to go...
Regards
Markus
[1]: http://www.json.org/
_______________________________________________
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
