(pRFP) an IPFS .eth websites pinning software

[neiman]

Good points!

I’d like to point out that there’s a second RFP planned if this one is approved:

@neiman

A subsequent RFP for operating a community service based on this software will follow upon the completion of this one.

The plan for the second RFP is for the DAO to fund 2-3 community services for pinning .eth websites (based on this software). The operation should be not expensive with such a software in place.

@taytems

Creating an IPFS cluster would allow a group of IPFS nodes to pin/host synchronised content. Alongside this I think it would make more sense to allow certain service providers to contribute, as opposed to making it entirely decentralised which has a significant amount of quirks.

The problem that was pointed out by the community in the .eth websites SG calls is that pinning is both decentralized and incomplete. I didn’t understand how using IPFS cluster would solve any of those issues?

Btw, did you ever try to run an IPFS pinning service? With the current software existing it’s quite a challenging work.

@taytems

Listening for ContenthashChanged events requires that a file is already pinned before it can be pinned into the proposed network. I understand your solution currently is that the user creates a CID themselves, but this is not at all a good user experience and therefore isn’t really a great solution to the problem.

We also discussed this in the .eth websites SG. The conclusion we came up with was written in the temp check that @gregskril made:

In our conversations, we realized that all of these services use Pinata’s API to upload/pin files to IPFS. This works perfectly as an on-ramp, but feels like a loss for decentralization.

Basically, we didn’t include uploading data because it makes development more complex, and it’s not necessary for solving the problems described in the RFP. It is something that we should add at a later stage to the software though, definitely.

@taytems

Listening for specific events limits the scope of proposal significantly, without benefit. It looks like there isn’t any explanation for why event listening is needed, and means that avatars and banners couldn’t be hosted on the service.

The proposal is for pinning .eth websites, and event listening is needed to determine when a websites was created or changed. Maybe it is indeed a good idea to add avatars/banners to it; we didn’t include it just to stay focused on the topic of .eth websites.

@taytems

The idea revolves around people hosting IPFS nodes without incentive, which isn’t a guarantee. Uptime of at least 1 node is important to make sure that existing pins are accessible, and that new pins can be made. Is there a plan for making sure that happens?

As written in the proposal, a subsequent RFP is planned for operating services based on this software.

@taytems

I think technical details should be detailed further, it seems like some aspects are unknowns (authentication, if/how nodes sync, etc).

We thought to leave these details to the those who will bid on this proposal.

Btw, you are warmly invited to the next call of the .eth websites SG! Everything you wrote is exactly the stuff we discuss there:-)