It's becoming error prone to support ssb:feed/ed25519/... URIs that don't neatly match ssb-bfe-spec. Since BFE has Type-Format, which closely matches ssb:Type/Format/... in many cases, it would be good to have parity, but BFE uses "classic" for the feed format, not "ed25519".
To reach parity, one of these specs (BFE or URI Spec) has to change.
Solution
I think ssb:feed/ed25519/... was already an outlier, because "ed25519" describes the crypto curve, not the feed format. Contrast with ssb:feed/bendybutt-v1/... and others, which use the same ed25519 crypto curve, but the name describes the feed format.
In this PR, we are addingssb:feed/classic/... which has the same use case as ssb:feed/ed25519/... while tagging the latter as deprecated. We still recommend all applications MUST support ssb:feed/ed25519/... but we can do a long-term transition to ssb:feed/classic/... and eventually remove ssb:feed/ed25519/....
Context
https://github.com/ssbc/ssb-private-group-keys/pull/14#discussion_r920695401
Problem
It's becoming error prone to support
ssb:feed/ed25519/...URIs that don't neatly match ssb-bfe-spec. Since BFE has Type-Format, which closely matchesssb:Type/Format/...in many cases, it would be good to have parity, but BFE uses "classic" for the feed format, not "ed25519".To reach parity, one of these specs (BFE or URI Spec) has to change.
Solution
I think
ssb:feed/ed25519/...was already an outlier, because "ed25519" describes the crypto curve, not the feed format. Contrast withssb:feed/bendybutt-v1/...and others, which use the same ed25519 crypto curve, but the name describes the feed format.In this PR, we are adding
ssb:feed/classic/...which has the same use case asssb:feed/ed25519/...while tagging the latter as deprecated. We still recommend all applications MUST supportssb:feed/ed25519/...but we can do a long-term transition tossb:feed/classic/...and eventually removessb:feed/ed25519/....