I recently worked on a project which used a large Bulletproof, leading to a reference string of ~200,000 points. In order to not generate these at runtime, I baked them into my binary with a build script. Unfortunately, at runtime, I must still load them into memory which is only possible via CompressedEdwardsY::decompress (or technically MontgomeryPoint::to_edwards). The point decompression is actually about as expensive as simply generating them outright (~2x faster, so it's still worth it, but this isn't optimal). If curve25519-dalek supported uncompressed point deserialization, even if checking the values are on-curve, this could be ~40x faster (as the curve formula check is ~20x faster than decompression).

There is a UncompressedEncoding API we can satisfy when the group traits are available. This would require the group traits be enabled and be unavailable in a const context however.

Without the group traits, we could define either EdwardsPoint::from_x_y(x: [u8; 32], y: [u8; 32]) -> CtOption<Self> or EdwardsPoint::from_x_y(x: FieldElement, y: FieldElement) -> CtOption<Self> depending on if #816 or #787 has been merged. For these to be const, we'd require being able to evaluate the curve formula in a const context. The fiat-crypto backends support this, and the inherent backends should as well, but their add, mul implementations are inlined into the Add, Mul traits. We'd have to move them to enable a public const fn add, const fn mul.

If the AffinePoint type was exposed, we should be discussing AffinePoint::from_x_y and AffinePoint::to_edwards. It isn't at this time, and I don't believe we need to expose it for this feature alone? The question is if AffinePoint is so ready to be marked pub, this tips it over the edge as a reason for why we should.