Lighthouse 🛠 Programmable Storage

Hello everyone, welcome to Eat India. Thank you for joining the Lighthouse seminar. I'm Ravish, and let's get started. So, at Lighthouse, we are building a Filecoin-based perpetual file storage protocol that gives you the ability to pay once and store files for a very long time. We are proud to be active participants in the Filecoin ecosystem for the past 2 years.

Our main focus during product development has always been on developers. So developers can focus on building their applications while Lighthouse takes care of their storage needs. At Lighthouse, we have Lighthouse Files and Lighthouse SDKs that you can use to quickly get familiar with the products and try out different features. Additionally, we have the Lighthouse JS SDK that you can integrate into your applications, and since IPFS and Filecoin since IPFS and Filecoin are public networks, users can use our library to encrypt files before uploading them to the IPFS network to ensure privacy. So, let's talk about programmable storage in detail.

This is something different that you won't find in most Web3 products. Suppose person X wants to store a file with two replications. One copy should be kept in the US and the other, say, in India other, say, in India . This is possible with just one line of code using Lighthouse programmable storage modules, and we will see how to do this soon. So let's start building.

First, let's take a look at the files tab. If you go to files.lighthouse.storage, you will see an interface where you can log in . You have the option to log in via Solana, EVM, or Web2 services such as Google and GitHub.

I will use the EVM option. This will launch my MetaMask. Let me in. And yes, here is the dashboard. You can upload a file, folder, enable encryption, or upload a file with encryption.

If you want to import a file from the IPFS network into Lighthouse, you can use the migration service. To use the SDK, you will need an API the SDK, you will need an API key, which you can create here. Let's say I need an administrator key. So, I write "admin". I click "generate click "generate ".

Yes. And here is my key. In addition, we have two more ways to create an API key, which we will learn about in the documentation section. If I go back to the dashboard and click on a specific file. I will get detailed information about the file.

Here is the file size. It was created here. This is the CID, which is a hash of the file. And if you go here, you'll find storage D. Let me click on it.

So, this took me to the Philox dashboard, where I see a few details. a few details. First, let's check the PC ID. So, this particular PC ID is the CID of the entire package that was sent to the Filecoin miner, and inside that package is my 0.55 kilobyte file, even though the entire package is 32 gigabytes package is 32 gigabytes .

So what happens is: at Lighthouse, we combine your files with other users' files to create a 32- create a 32- gigabyte bundle, and then send it to a Filecoin miner. OK. Yes. Also, if you want to view the file, you can simply copy the CID and go to gateway.lighthouse.

storage. Insert it here, and there it is. Alternatively, you can view the file directly in the dashboard. So yes, some formats are not supported, but images and video files can be viewed directly from the control panel. Now let's get back to the presentation.

OK. So, this diagram shows the entire file path from the user to the storage miner. When a user uploads a file through Lighthouse, it is initially stored on the Lighthouse IPFS node. From an IPFS node, you can instantly view the file using the gateways using the gateways I just demonstrated. Also, once a file is successfully uploaded to an IPFS Lighthouse node, our transaction engine finds the file and merges it with other users' files.

Once the 32-gigabyte package is ready, this file is sent to the Filecoin miner, and the Filecoin transaction is complete. After that, you can see the Filecoin transaction on your dashboard. Now let's move on to the documentation. You can go to docs.lighthouse.

storage. You can get a brief overview in the Introduction section. In the quick start guide, you'll see how to put all the elements together and instantly upload a file. Creating an API key will show you the SDK method. If you are using are using any other programming language other than JS programming language other than JS , you can use the API.

So all sections will also contain APIs. So, if you are building in Rust or Go, you can integrate using the API, and if you are using our CLI tool, you can refer to the CLI section. Then you can download the data. When loading data, you can load a file, JSON, or buffer. If you want to encrypt data and then upload it to IPFS, you can encrypt the file, encrypt the JSON, and refer to the encryption section.

In addition , we offer additional encryption features, such as file sharing. Let's say I downloaded an encrypted file; when another user receives it through the IPFS gateway, they will download a binary file that they cannot simply decrypt. So, to make this file available for viewing by a specific user, you can use the P2P use the P2P sharing method. You simply provide their wallet address, authenticate via signature, and the file will become available for viewing by the other user. If you want to revoke access for this user, refer to the section on revoking access.

Apart from that, you can also use token gating. In token gating, you can apply access conditions, for example: unlock this file after a certain number of blocks. Let's say you want to share a file with a friend on their birthday. You can do it exactly like this. Or, if you have an NFT collection deployed on deployed on any network, like Polygon or Ethereum, you can create a condition: if a certain user owns an NFT from my collection, they can view that file.

Even such things can be implemented. If you go to the access control conditions section , you will see all the available condition types. The first is the "balance of" condition types. The first is the "balance of" . This is just an example with NFTs.

You can call the balance check method and determine whether the user owns this NFT. There are also their own smart are also their own smart contracts. If you have your own ready-made contract, you can define a function to call, set parameters, and allow another user to decrypt the file. You can also check for the presence of a native token. For example: if a user has 1 ETH, give them the ability to decrypt the file.

Even that is possible. For time-based conditions, you can check out the blockchain support section to see all current networks. You only need to specify their name in the terms of access. We will look at this in more detail in the demo section demo section . Let's look at the rest of the features.

Use the file list to view all the files you have uploaded to Lighthouse. You can check the metadata in the file information section. Namely: file size, CID, whether it is encrypted, file name, and MIME it is encrypted, file name, and MIME type. Next comes obtaining the balance. You can simply check your balance.

So how much data limit do you have left, then you can use receive directly if you want to receive a file from the gateway, and if your Filecoin transaction is ready, you can just check the status of your transaction and you will get something like this. So, the main thing is this transaction ID in the chain, you can find this ID on Phil Fox and get information about this specific transaction even in the chain itself. Because CID chain itself. Because CID is a hash of the file. So if you change even one bit in this file, the entire hash will change.

So, if you have a changing file that you upload over and over again, but you need a permanent need a permanent URL. In this case, you can use the IPNS service, where the IPNS service, where the URL will remain unchanged. You only need to change the hash pointer. So you can refer to the IPNS section. It's pretty simple, just four steps and you're all set.

Next is set. Next is file migration if you want to import all CIDs in bulk from the IPFS network into Lighthouse. Then we have a pinning service. It works, if you have a separate CID that you just want to pin to Lighthouse, you can use the pinning service. Pay-per-use: not all users are ready to buy, say, 100 GB at once.

Maybe you need to store 100 GB of data permanently. In that case, we created a service called " a service called " pay per use" where you can get a price. Get a price, for example, for 100 megabytes. You simply specify the file size and then the network you need. We currently support the Filecoin mainnet and Calibration net.

And if you want to use a native token, just enter “native,” or if you want to use a stablecoin, you can enter “USDC.” And for the Calibration network, it is USDT. So, you will get a price. Whatever price you get, just enter it here. You can complete the options, sorry, the financing function financing function , and you can pay.

After payment, your data limit will automatically increase and you will be able to download as many files as you need, for example 100 MB, 200 MB . And if you want the upload to happen in real time and you haven't generated an API haven't generated an API key or anything like that key or anything like that , you can also generate a one-time token that will expire after the upload. Now resize the image. So, in the case of the gateway, if you get an NFT if you get an NFT collection and, let's say, the file is 1920x1080 and you need 240 by 250 to display it nicely on the site, that will also save space. You can use the image resize feature where you can specify the height and width of the file and the system will resize it and display it for you.

If you are experimenting with our CLI tool our CLI tool , you can refer to this section. Now let's upload the file. So, I open my VS Code. I already took this code from our documentation. To upload a file, you need two parameters.

The first is the file path, and the second is the API key. You simply call lighthouse.upload, import the library, environment variables, and specify an absolute path, not a relative one, and provide an API key, and the file will be uploaded. If I just go to load the index load the index , there it is, and if I want to view the file, I can just copy the hash, go to the gateway, replace the C, and there it is. OK.

Let's go back to the presentation. Okay to the presentation. Okay . Now let's look at programmable storage programmable storage . To use programmable storage programmable storage , you simply need to call a RAS worker, and Lighthouse will take care of the rest in the background .

It works like this: you can send your CID via a transaction in a contract or call the API with a POST request, which I will demonstrate now. Once the request is registered with the RAS is registered with the RAS worker, it will take this CID and pin it to our IPFS node. Once pinned, the transaction engine will take this file and upload it to the Filecoin network. OK. When the agreement expires, and if you have configured a file refresh condition, the RAS file refresh condition, the RAS worker will re -pin the file to the IPFS network.

So, the file is re-pinned until the transaction is complete, and the transaction engine picks it up and sends it back to the Filecoin miner. Thus, even before the current agreement expires, you get a new one. So the transaction is created continuously is created continuously , and we use this RAS use this RAS worker quite actively in our perpetual storage model. If you want to use the RAS want to use the RAS worker, let me jump to the RAS code example. I'll close this.

Okay, I'm closing the other window. Not this. Good. So, to register your CID register your CID , you only need the CID itself, and the other parameters can be left at default, although you can define them if you wish. So, I created a sir and then created a contract object.

You will also find the contract address in the documentation. Additionally, I have placed this code in my git repository. You can find all the code examples I demonstrate here on my GitHub. Next, I created a contract object. This is my CID that I want to register.

I converted the CID to hexadecimal format. Now I call the submit deal function. So, the first parameter is the CID. The second is the number of replications, how many copies you need. The third is the expiration date of the agreement.

If a miner does not fulfill the transaction, he does not provide proof. So, after how many epochs, if a default occurs, the agreement must be renewed, i.e. a copy must be created with another miner, and the last miner, and the last is the increase in time before expiration. You can determine how many days before the agreement expires that you need to renew it.

Let's assume that on average, 2880 epochs occur per day in the Filecoin network. So, if you want to do it 10 days before the deal expires, you just put 28800. like that, and it will work. So if I do this it will take a little while. The transaction takes about a minute.

So, to save time, let's check the status of the deal and discuss the code part. Once your CID is registered on the testnet, you will receive a transaction within 20–25 minutes and you will be able to check the status of your transaction using this API. Everything is also in the documentation, you can refer to the FBM section. So, calibration.lighthouse.

storage API deal status, insert your CID. OK. For this specific CID, an agreement has already been created and you will receive the following response. These are current active deals. It was the transaction ID.

These are transaction identifiers. Okay, let's check one out in Filfox check one out in Filfox . On the Calibration network, you go to the deals section and simply insert your deal ID. and here he is. You can check Filecoin miner, transaction size is 16MB.

In the test network, the miner supports files from 4 megabytes in size . So you can create deals even for small files . The transaction has been completed. You get this answer. OK.

So once the D list is created, you can use portsai uh, this is to get a confirmation of the file. So, I'll give you a quick overview of what's happening: we use this file verification data to recreate this PC ID, and this PC ID you can verify online. It must match this PC ID. This means that the PC ID we are showing actually has a record on the network, and using these file verification options proves that your file was part of that specific PC ID. So you can be sure that yes, my file is in that 32- that yes, my file is in that 32- gigabyte package .

Returning to the presentation. We have already briefly discussed programmable access control. How it works from the inside: we generate a random key on the user side. This key is broken into five parts, and these parts are independently stored on five different nodes. These nodes are currently hosted on Lighthouse, but we also have a plan for decentralization, and we use this random key to encrypt and upload the file to IPFS.

This way, you get an encrypted file uploaded to the IPFS network. Similarly IPFS network. Similarly , for decryption, you simply request parts of the key, generate the original key on the user side, retrieve the file from the IPFS network, and decrypt it. Well, we also have a passkey feature in encryption where you can use your fingerprint or mobile phone to decrypt the file. In the documentation you can find the passkey here, in the authentication section.

You can even refer to this. The next point is to verify the file that we just discussed. Now let's move on to the rewards. We have two rewards. The first is for the best use of our programmatic access features—$2,000, and the best overall use of the Lighthouse SDK use of the Lighthouse SDK , split between the two teams— $3,000.

Here are some common uses. You can create eternally recoverable storage using these programmable data stores, DAOs, time- locked access conditions, etc. Okay, if you have any questions, you can write to me on Twitter, Telegram, or you can also write to us on Discord. This is Discord Lighthouse, and you can even write to us on the global Discord. Yes, thank you.