Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

compressed cid set implementation #239

Open
Gozala opened this issue Jan 13, 2023 · 2 comments
Open

compressed cid set implementation #239

Gozala opened this issue Jan 13, 2023 · 2 comments
Assignees

Comments

@Gozala
Copy link
Contributor

Gozala commented Jan 13, 2023

I believe @mikeal has compressed CID set representation & implementation. CID sets come up all the time and we always resort to some hacky version like maps with CID keys or sorted lists to represent them.

I think it would make a lot of sense to just standardize compressed CID format and implementation. I would suggest:

  1. Implementing a codec for the compressed CID set representation and adding it here.
  2. Defining a codec format and allocating a code in the multitcodec table
@rvagg
Copy link
Member

rvagg commented Jan 23, 2023

A new codec specifically for this would certainly qualify as a new codec, if it uses an novel encoding method. IIRC this is novel.

The qualification is something like: "an IPLD codec is something that potentially yields links and whose decoding method isn't already covered by an existing codec".

I guess the data model form would always be something like [&Any] - but we'd want details about the edges of that - is it nullable, is zero-length acceptable, is there a maximum, can they repeat (does it matter), etc. But a quick spec doc about that in the codecs list would be enough.

@Gozala
Copy link
Contributor Author

Gozala commented Jan 24, 2023

I guess the data model form would always be something like [&Any]

I would argue we do need sets at the data model layer as well. It really is painful that one doesn't exists already, precisely because [&Any] does not say convey set semantics, in fact we find ourselves using { String: &Any } instead for that exact reason, however that isn't ideal either because how you key them becomes another question which can lead to less deterministic outcomes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants