Establish an initial SLA for "free deployment & persistence"

[dOrgJelli]

SLA - Polywrap Alpha

Approval

TODO: ratify this SLA, and all future updates, via DAO vote.

Service

Wrapper Persistence - Wrappers will remain online and available for clients to download. The persistence nodes running at ipfs.wrappers.io will be treated as the primary provider of said service.

Lifetime

Begin: Polywrap's Alpha Release End: Undefined

Note: Polywrap DAO reserves the right to make any changes to this agreement but will provide a minimum of 90 days notice before doing so.

Agreement

A. ENS Domain Records

Wrapper developer agrees to:

• Set the content record of an ENS domain on mainnet which uses the public resolver.
• content record must be an IPFS hash.
• IPFS hash must point to a valid wrapper (see definitions below).

In exchange, Polywrap DAO agrees to:

• Make the wrapper located at the IPFS hash available for free indefinitely through ipfs.wrappers.io.

B. ipfs.wrappers.io Deployment

Wrapper developer agrees to:

• Post an IPFS hash to the ipfs.wrappers.io service's designated deployment endpoint.
• IPFS hash must point to a valid wrapper (see definitions below).

In exchange, Polywrap DAO agrees to:

• Make the wrapper located at the IPFS hash available for free for 24 hours through ipfs.wrappers.io.

C. IPFS Seeding

ipfs.wrappers.io agrees to publicly seed all of its indexed wrappers over the public IPFS P2P network. ipfs.wrappers.io makes no availability guarantees for wrappers downloaded through 3rd party IPFS gateways.

Definitions

Valid Wrappers

1. < 10 mbs
2. Valid manifest files
3. Valid artifact files (wasm, schema, etc)

[dOrgJelli]

Requesting review: @nerfZael @evanjacobs @eugenefine

[dOrgJelli]

NOTE: we should probably create a repo for aggregating these SLA documents.

[eugenefine]

NOTE: we should probably create a repo for aggregating these SLA documents.

should we add the SLA management topic to the Technical Council agenda?

[dOrgJelli]

Great idea @eugenefine, yes I think this should be a high priority topic.

[evanjacobs]

Can we frame this in terms of what each party (wrapper developer and Polywrap) is agreeing to?

Wrapper developer agrees to:

• set an IPFS hash within the content record of the related ENS domain
• limit the size of the wrapper to 10 MB
• include a valid manifest file
• includ valid artifact files

In exchange, Polywrap agrees to:

• make the wrapper available for free indefinitely through ipfs.wrappers.io

Questions:

1. What do you mean by "grace period" under the Lifetime section?

[dOrgJelli]

I like this framing @evanjacobs, will rewrite the "agreement" section based on this.

What do you mean by "grace period" under the Lifetime section?

This is intended to go into effect once an SLA end date has been defined. For example, if we decide to end this SLA January 1st 2023, then there will be a 3 month grace period for users to stop relying upon this agreement (until April 1st).

[dOrgJelli]

Update @evanjacobs

[evanjacobs]

I updated the "grace period" language to be a bit more clear but otherwise this LGTM.

Note: We still need to do some financial modeling for how expensive it is to offer this service but I think we'll be fine for the foreseeable future and we can revisit this sometime after Alpha launch.

[nerfZael]

Couple of questions:

1. What networks does this apply to? (mainnet, rinkeby, ropsten). I wanna say mainnet, but wanted more opinions on this
2. Does free persistence imply that we're sharing/seeding the wrappers over IPFS or just making them available through the ipfs.wrappers.io gateway?
3. Do we need to protect against spam attacks? e.g. deploying wrappers of 9.99 MB in size every second. I'm thinking probably not for alpha

Otherwise LGTM.

[dOrgJelli]

@evanjacobs do you think we should phrase it Polywrap DAO reserves the right to make any changes to this agreement but... instead of Polywrap reserves... to make it more clear who the governing body of this agreement is?

[dOrgJelli]

@nerfZael

1. What networks does this apply to? (mainnet, rinkeby, ropsten). I wanna say mainnet, but wanted more opinions on this

I propose this be specific to mainnet to protect against potential spam. In order to be indexed, it will require a "real world" value to be incurred. I'll update the language to be specific to this, great catch!

I've also added a hyperlink to the ENS public resolver so that viewers know which contract will be indexed.

Started a conversation with you regarding this "public resolver constraint" here.

2. Does free persistence imply that we're sharing/seeding the wrappers over IPFS or just making them available through the ipfs.wrappers.io gateway?

That's a great question. I think that we should add a sentence saying "In addition, ipfs.wrappers.io will be publicly seeding packages via IPFS, but makes no availability guarantees when 3rd party IPFS gateways are used." Will add this, let me know if you disagree.

3. Do we need to protect against spam attacks? e.g. deploying wrappers of 9.99 MB in size every second. I'm thinking probably not for alpha

No I don't think we need to worry too much. If we use mainnet, it's way too costly to spam the system. If we choose to add support for test networks like Rinkeby then I think we'll need to look at a simple heuristic to see how feasible it is to overload the system with testnet ETH.

[dOrgJelli]

@evanjacobs do you think we should include some notion of "expected budget" here? This way voters have an idea of what this will roughly cost so expectations can be clear.

[evanjacobs]

@evanjacobs do you think we should phrase it Polywrap DAO reserves the right to make any changes to this agreement but... instead of Polywrap reserves... to make it more clear who the governing body of this agreement is?

Yep, that's more clear

[evanjacobs]

@evanjacobs do you think we should include some notion of "expected budget" here? This way voters have an idea of what this will roughly cost so expectations can be clear.

Yeah, some quick math on expected budget would probably be helpful for voting purposes.

[eugenefine]

Here some questions that maybe relevant to SLA discussion:

• what is the commitment of services availability per calendar month (uptime %)?
• is the a services status page? status history?
• how is "down time" managed? is there a notification commitment and what frequency/channels?
• is there maintenance process? notifications? status page?
• is user/developer support offered? what format and channels? how is support requested and managed?
• what monitors should be implemented and managed to validate services uptime?
• what services availability and scalability testing should be performed (high availability tests, stress tests, etc.)? what frequency?

[dOrgJelli]

I've updated the agreement, and will post to the forum for initial discussion, then snapshot there after.