You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We need this to help get around problems posed by trying to store large blobs in HC directly. For example, we can't use the time tracking app because it's too big and can't be stored on the source chain. I imagine that many capabilities that will get built will need to use external libs and their size will only increase as the platform adds more users. However, we will also be using this for storing user content and the resource schemas and resources themselves.
The basic criteria are:
Has a client that can break apart large files/blobs into microblobs and store those microblobs indexed in HC.
Should be able to store blobs both locally in the source chain and in the DHT.
Keeps track of what blobs have been stored, including MIME type, optional filename, and optional description.
Keeps track of the microblobs that are stored for each larger blob.
Ensures ordering of the microblobs.
Supports fetching a small number of microblobs asynchronously and reordering them into correct order on the client side (this is for streaming larger files).
Optionally: able to keep track of which peers have which file locally (like Napster or BitTorrent), and each peer should have an interface for bridged calls to stream parts of files. Then high bandwidth video (like meeting recording) could be streamed from multiple active peers at the same time lessening the load required of each peer. That way when there are a certain number of peers, video can be streamed.
Weird thought: We already have the signaling server that is necessary to use HC's WebRTC backend, why can't we just stream files directly to other clients based on that? Is it because of security restrictions or because we need certain workarounds that libp2p implemented? Anyway, if you have time, maybe investigate using the WebRTC signalling server for things like that.
Are there other implementations out there? Yes. Let's have a look at them:
We need this to help get around problems posed by trying to store large blobs in HC directly. For example, we can't use the time tracking app because it's too big and can't be stored on the source chain. I imagine that many capabilities that will get built will need to use external libs and their size will only increase as the platform adds more users. However, we will also be using this for storing user content and the resource schemas and resources themselves.
The basic criteria are:
Are there other implementations out there? Yes. Let's have a look at them:
The text was updated successfully, but these errors were encountered: