Indexing component implementation

[serg-temchenko]

As described in our guidelines, this component should store indices of deal data so that it can be retrieved by a content identifier (CID).

[jmg-duarte]

As per the "New Boost setup" docs (step 5)

boostd-data is a data proxy service which abstracts the access to LID through an established API. It makes it easier to secure the underlying database and not expose it. boostd-data listens to a websocket interface, which is the entrypoint which should be exposed to boostd, and booster-http

The LID is fronted by the boostd-data service and the LID itself is just the database.

So my question is, isn't this redundant to #24?

[serg-temchenko]

As per the "New Boost setup" docs (step 5)

boostd-data is a data proxy service which abstracts the access to LID through an established API. It makes it easier to secure the underlying database and not expose it. boostd-data listens to a websocket interface, which is the entrypoint which should be exposed to boostd, and booster-http

The LID is fronted by the boostd-data service and the LID itself is just the database.

So my question is, isn't this redundant to #24?

You are right. This issue might be treated as a sub-task for #24. Right now it is in a backlog, and assigned on me, but the #24 is on you. This part is something that should be consumed in a process described here.

When file is received and processed. If you don't mind, I'll assign it on you, since I'm working now on accountId/key pairs management.