Test Terms
You are joining a test release. These terms describe the system you are actually joining, and nothing else.
1. What this is
1.1. ServerShare is a platform where people rent out spare computing capacity of their own machines, and other people rent that capacity to run their workloads.
1.2. The platform is in a test release. It is operated by the people building it, and there is no legal entity behind it. These terms are a description of how the system behaves, not a contract with a company.
2. Money
2.1. The platform neither accepts nor pays out money. There is no payment, no payout and no withdrawal.
2.2. Usage is accounted for in test credits. Credits are issued by an administrator, exist only inside this platform, and have no monetary value. A credit balance is not a claim to anything outside the system.
3. What is collected and what is stored
3.1. The platform records what your machine is — processor, memory, disk, accelerator, operating system — and what you do inside the product: the machines you order, the sessions you run, the agents that connect.
3.2. The platform also stores content you send out of a machine yourself. Results synchronised out of a rented machine are kept by the platform, counted against your storage quota, and listed back to you.
3.3. That content is encrypted inside the machine, before it leaves it. The key belongs to you and is held by the server. The owner of the hardware your machine runs on does not have that key and cannot read what you stored. Who can read it is the question you are actually deciding when you turn synchronisation on, and this is the answer to it.
3.4. Stored content has a retention period. The platform shows you that period, warns you before the deadline, and deletes the object once it passes. Anything you want to keep beyond the deadline has to be downloaded before it.
3.5. You can ask for your stored content to be deleted earlier than that, and for everything under your account to be deleted when you stop using the platform. Ask through the same Telegram bot your invitation came from.
3.6. If you tell that bot something about yourself, it is stored as the message you sent, and nothing else is derived from it.
4. What you must not put in
4.1. Do not upload personal data about other people — in particular photographs or likenesses of people who have not agreed to it. This includes datasets you assemble for training.
4.2. This is not a formality. A rented machine runs on hardware belonging to another participant, and on a Community host that participant has the technical means to observe the computation while it runs (see section 5). The platform cannot promise otherwise today, and so it cannot accept other people's faces.
4.3. The restriction describes the state of the system rather than a position of principle. Hardware attestation of hosts is what would lift it; until that exists, the answer stays the same.
4.4. The platform does not inspect what you upload and cannot know what is inside it. Whether what you upload is yours to upload is your responsibility.
5. The host is semi-trusted
5.1. A rented machine runs on hardware that belongs to another participant. While a session runs, the owner of that hardware has the technical means to observe the computation, and the platform does not prevent this. This is the trust model of the product, not a defect of it.
5.2. Your data on the machine's data volume is encrypted with a session key. The key is held by the server, not by the host owner. When the session ends the key is destroyed, and with it the data on that volume. The key that protects what you sent out of the machine is a different one and outlives the session — see 3.3.
5.3. The machine is redeployed from its image on every start. Nothing inside a machine survives its session. Results you want to keep have to leave the machine before it stops; what leaves it is kept as described in section 3.
6. No guarantees
6.1. A host may go offline at any time, including in the middle of your session. A build may fail. The platform is being tested, and neither availability nor the preservation of anything you run is promised.
6.2. Renting out your own machine grants you no access to what runs inside a tenant's machine on it, and renting a machine grants you no access to the host it runs on.
7. Accounts
7.1. Access is by invitation. An invitation link is issued through the Telegram bot and lets you set your own password.
7.2. You are responsible for what happens under your account. An account may be suspended by an administrator, with the sessions running under it.
7.3. Using the platform also means following the Acceptable Use Policy. Renting out a machine of your own additionally means accepting the Host Terms.
8. Developers using the model API
8.1. The model API lets you send requests to models served by machines in the platform's pools, with an API key you create in the panel. A key is a secret: anyone holding it spends your credits. Revoke a key you suspect has leaked.
8.2. You are responsible for your application. If you build something on top of the API — a product, a bot, a service for other people — you are responsible for what that application does, for the people who use it, for what they send through it and for what you do with the answers. The platform has no relationship with your users and does not answer to them.
8.3. A request is processed on a machine that belongs to another participant, and that participant is semi-trusted in the sense of section 5 — unless it is sent to an external model provider under 8.7, in which case it leaves the platform. Do not send through the API anything you would not accept being seen by the owner of that hardware — in particular personal data of other people, credentials and secrets.
8.4. The platform records each request — the key, the model, the machine that served it, timings, token counts and the credits charged — and does not store the text of requests or answers.
8.5. Answers are produced by models and may be wrong, incomplete or unsuitable for your purpose. Nothing a model returns is a statement of the platform. Do not rely on answers where a mistake could harm someone without a person checking them first.
8.6. Requests are limited per minute per key and per account, and are charged in test credits. The limits, prices and the list of models may change at any time during the test.
8.7. When no machine of the platform can serve your request, it may be sent to an external model provider instead of failing. This is switched on for individual models by the platform's administrator, and it is off unless switched on. A request handled this way leaves the platform: it is sent to that provider under the platform's account with them, it is subject to their terms and their handling of what you send, and the platform does not control what they do with it. Each such request is marked in your usage log with the provider's name — the "Served by" column of the usage section of the developer console — so you can always tell where an answer came from. If you do not want your requests leaving the platform, check that mark; a model with no provider behind it never leaves.
9. Changes to these terms
9.1. These terms have a version. When a new version is published, the panel shows it to you and asks you to accept it before you continue. The version you accepted and the time you accepted it are recorded.
Version 3