Project Name: Sia Satellite
Project Lead: Michael Bulanov
Developer: Michael Bulanov
Sia Satellite has reached the public beta stage, and the first Satellite node is launched (https://ss-alpha.online). The purpose of the testing, in addition to removing any revealed bugs, is to gain the statistical data as per what the operational costs of running a Satellite node shall be.
Despite running in the test mode, the service is fully operational. The renters can pay for the service in fiat money on the portal, and then use the Satellite to upload and download files with the renting software such as
renterd. All crypto currency-related aspects (except the contract details, which are reported in Siacoins (SC) for the convenience) remain hidden from the renter.
With this proposal, the project lead intends to address further unmet needs in the decentralized storage space.
The project lead believes that the only one obligation of a customer (read: a renter) should be to pay in time for the services they receive. Currently, the renters need to keep their nodes running in order to maintain the health of their data. This is inconvenient, so the renters could delegate more responsibilities to a Satellite, which could then be monitoring the health of the data and re-uploading the shards to the new hosts if the data redundancy dropped below a certain threshold.
The same as above, the renting software running continuously takes care of the contracts that are expiring and renews them. A Satellite could perform automatic renewals of such contracts, so the renters would only need to maintain a positive fiat balance with the Satellite. This feature is already partially implemented: the RequestContracts RPC sends the contracts that the Satellite has formed, to the renter.
If a renter accidentally loses the metadata of their files, then these files are usually gone. A Satellite could keep a copy of the metadata in its database allowing the renter to recover the files.
A Satellite could act as a proxy when the renters upload their files to multiple hosts. Instead, the renters could upload the files to the Satellite only, thus saving the bandwidth.
All the options above shall be on the opt-in basis, because they imply certain levels of trust.
- Once multiple Satellite nodes are deployed, the renters should be able to switch from one Satellite to another as seamlessly as possible.
Further action items may arise based on the community feedback during the testing phase.
Like always, the project source code shall be maintained in the public repository located at GitHub - mike76-dev/sia-satellite: A network service that allows credit card payment for Sia storage..
The project shall have the following milestones:
- Automatic contract renewals (May 23)
- Renter metadata backup (Jun 23)
- Upload proxying (Jul-Aug 23)
- Automatic repairs (Jul-Sep 23)
- Deployment of the second Satellite (Aug 23)
- Common satellites database and migratable user accounts (Sep-Oct 23)
In addition to the milestones mentioned above, some improvements to the existing codebase are planned:
- General cleanup of the satellite code
- Optimization of the HostDB code
- Support of the upcoming
- Redesign of the web portal
There are a few external risks to the project:
- Denial of services from the cloud server provider(s) due to the violation of some of their policies (anti-spam, anti-abuse, etc.) For instance, Hetzner was notoriously mentioned for being very much intolerant to their customers’ activities; for this reason, OVH was chosen as the provider for the first Satellite.
Severity: medium, likelihood: low, mitigation: easy.
- Denial of services from the payment processor (Stripe) due to the violation of their policies (mainly high-risk activities). Some work has already been done to mitigate this, and a general course of action for the Satellite operators has been developed. In the worst-case scenario, it may become necessary to switch to more tolerant payment processors (e.g. PaymentCloud).
Severity: medium, likelihood: medium, mitigation: difficult.
- Denial of services from the mail services provider(s) due to the violation of their anti-spam policies or due to the implementation of more stringent security measures. Can be easily mitigated by choosing another provider. Severity: low, likelihood: low, mitigation: easy.
- Unavailability of the exchange rate providers (e.g. in certain regions). Can be easily mitigated by switching to another provider. Severity: low, likelihood: low, mitigation: easy.
All the risks listed above are more related to running a Satellite node rather than to the project itself. There are also internal risks related to the scalability of the satellite. So far, it is unknown how the satellite will perform under load. The tests will show that.
The project is requesting 48,000 USD for the following six months. The requested amount shall constitute the full-time salary of the developer, paid monthly at the beginning of each month.
The costs of the server infrastructure and of the testing of the services within the project timeline have already been covered by the previous grant, and their reimbursement is not requested in this proposal.
The progress of the development shall be reported on a monthly basis in the Forum and in the community Discord.
The project lead is kindly asking the Foundation to review this proposal. He is also encouraging the community to ask as many questions as possible.