Refer to internal representations instead of Edwards points

[str4d]

The README currently contains language like:

The ristretto technique gives a way to map ristretto255 group elements to Edwards points (fromBytes()) and to convert a certain subset of Edwards points back to ristretto255 group elements (toBytes()).

This suggests to users that it is potentially valid to convert between ristretto255 group elements and Edwards points, and use the latter in other contexts. This is not the case, as the ristretto255 RFC draft strongly states in section 4 (and elsewhere in the spec):

ristretto255 is an abstraction which exposes a prime-order group, and
ristretto255 elements are represented by curve points, but they are
not curve points. The API needs to reflect that: the type
representing an element of the group SHOULD be opaque and MUST NOT
expose the underlying curve point.

It SHOULD be possible for a ristretto255 implementation to change its
underlying curve without causing any breaking change. A ristretto255
implementation MUST be interoperable with any other implementation,
even if that implementation uses a different curve internally. Any
operation on ristretto255 elements that only works correctly or leads
to different results based on the underlying curve is explicitly
disallowed.

In particular, implementations MUST NOT define the ristretto255
functions as operating on arbitrary curve points, and they MUST NOT
construct group elements except via "DECODE" and
"FROM_UNIFORM_BYTES".

However, it is RECOMMENDED that implementations don't perform a
"DECODE" and "ENCODE" operation for each operation in Section 3.3, as
it is inefficient and unnecessary. Implementation SHOULD instead
provide an opaque type to hold the internal representation in between
operations.

I presume that limitations of JavaScript prevent you from providing an opaque type that contains the internal representation as an Edwards point (thus making the safe APIs perform a DECODE and ENCODE operation for each API operation). An opaque type is strongly preferred, but if it is not possible, then the language in the README should be altered to ensure that users understand they MUST NOT operate directly on the internal representations (beyond the specific unsafe APIs provided) under any circumstances.

[Kevin Lewi]

Thanks for pointing this out -- README updated.