There are a couple legacy decisions in this library that are still haunting us. Like feedpurpose instead of purpose, it's cemented in the spec and not worth changing it. But also details.subfeed. The worst is when details refers to the root metafeed, and thus details.subfeed is the id of the root metafeed. Disgusting! Someone will definitely feel confused by this API.
Also, the branches as tuples [id, details] was getting really obnoxious to work with, when it could just be details.id etc.
Solution
We can keep the spec untouched while making this library return more reasonable.
details.metafeed => details.parent
details.subfeed => details.id
details.feedpurpose => details.purpose
details.feedformat => details.feedFormat (this one can't be format because we also have details.encryptionFormat)
Problem
There are a couple legacy decisions in this library that are still haunting us. Like
feedpurposeinstead ofpurpose, it's cemented in the spec and not worth changing it. But alsodetails.subfeed. The worst is whendetailsrefers to the root metafeed, and thusdetails.subfeedis the id of the root metafeed. Disgusting! Someone will definitely feel confused by this API.Also, the branches as tuples
[id, details]was getting really obnoxious to work with, when it could just bedetails.idetc.Solution
We can keep the spec untouched while making this library return more reasonable.
details.metafeed=>details.parentdetails.subfeed=>details.iddetails.feedpurpose=>details.purposedetails.feedformat=>details.feedFormat(this one can't beformatbecause we also havedetails.encryptionFormat):bomb: This is a breaking change.