Deprecate HTTP(S) Transactions #54
Conversation
There was a problem hiding this comment.
Nice job turning this around so quickly, @Joltz.
Couple of comments regarding the text, see separate comments.
On a more meta-level, in Tuesday's meeting you wrote:
We could just say: "it is unacceptable for grin to have default transaction methods that are not private by default" or something.
Did you consider writing an RFC on that topic instead? I.e. rather than the specific case against http(s), instead making a much more general case arguing for a ban on any current and future transaction building methods that are not privacy-preserving by default (and offering some definitions for what should be the criteria for such evaluations).
Such an RFC would have a longer "shelf life", and would be applicable to future methods as well. And then whether we keep/reject http(s) becomes more of an "implementation detail" rather than something we need to RFC specifically.
Just a thought. I also see the appeal for a more to the point worded proposal about http(s), still, I'm wondering whether it would be even more powerful if we formalise a general view on methods we want Grin to support.
|
Thanks for the detailed review @lehnberg!
The reasoning for giving this its own RFC was that since deprecating HTTP(S) is such a major change, it might need its own slot to get enough attention and to avoid catching anyone by surprise. One idea is that once deprecate-http-tx, armored-slates, compact-slates, slate-serialization, slatepack-metadata etc RFCs are done we could converge on a "Standard Transaction" RFC that would be the minimum viable transaction that any wallet or service should support. Beyond a "standard transaction", other optional methods could be used as long as they inform users of the risks. So assuming slatepack/armored slates are adopted as the "standard transaction" they would be supported by all wallets and services, with Tor (or any other method adopted) offered as an optional convenience.
I think this would be positive in general. It would help us prioritize acceptable tradeoffs when looking at possible future transaction methods. This might be more nebulous to iron out in the detail needed for a RFC as opposed to adding, removing or converging on a specific transaction method though. Overall I'm not sure what is best: trying to push toward a path with a "standard transaction" that is universally supported or trying to push toward a path that may not have a universally supported transaction but doesn't have any options that are not acceptable according to higher order values like "privacy by default". Those aren't mutually exclusive either and the latter path may ultimately help forge the "standard transaction" path. |
|
core is still undecided about https? |
|
Assigning @Paouky as shepherd |
There was a problem hiding this comment.
(DIdn't mean to request changes, but I can't change it now).
users and services will be encouraged to use more privacy-friendly transaction methods like Tor or directly exchanging armored slates.
For the average user this means that to send or receive Grin they can use the Tor method or file exchange (potentially to be replaced with armored slates). It is no longer possible to send and receive Grin via the HTTP(S) method without custom configuration.
asynchronous exchange of armored slate strings or files
Should we update this to be coherent with the Slatepack terminology, for the sake of clarity when it's referenced in the future?
Kill the https! |
|
I updated the RFC to reflect the Slatepack changes. Please let me know if anything could be clarified to help make this transition as easy as possible for developers and services to follow. |
|
This RFC enters its final comment period (FCP). Please voice any possible concerns during this 2 week period. |
|
This RFC is due to be merged by October 28 unless there are significant comments and objections raised. |
|
👍🏽 |
|
👍 |
|
In line with our governance process, this RFC has now been merged 🚀 |
|
@jaspervdm fixed: #74 |
Rendered link to RFC document