Para quem é
Uma máquina que já fica ligada — um NAS, um Raspberry, um pequeno servidor caseiro, uma caixa num rack que já paga — com um gigabyte ou mais de espaço de que não precisa, na mesma LAN que um node Sensmos. Linux com Python 3, nada para instalar além do próprio script. Root só é preciso para escrever o ficheiro de estado e a unit do systemd.
O comprador é sempre outro dono de node: o Store é comércio interno entre pessoas que têm nodes, não uma nuvem pública. Nunca lida com o comprador diretamente; o backend escolhe vendedores, move os bytes e fecha os dias.
O que guarda de facto
Blobs cifrados. A app do comprador cifra cada ficheiro no telemóvel com uma chave derivada da assinatura da carteira dele; o que lhe chega é texto cifrado com um id aleatório. Não recebe chave, nome de ficheiro nem nada que identifique o comprador. Do seu lado não existe caminho no código capaz de decifrar — o agente é um único ficheiro legível, veja por si.
Início rápido
Execute isto na máquina que vai guardar os dados. Fala uma vez com o seu node, pela LAN, e daí em diante só com o backend.
# 1 — obter o agente (um ficheiro, só biblioteca padrão)
sudo curl -fsSL -o /usr/local/bin/sensmos-store.py https://sensmos.com/ext/sensmos-store.py
sudo chmod +x /usr/local/bin/sensmos-store.py
# 2 — emparelhar através do node: o endereço dele na LAN, o PIN, um nome, onde guardar os blobs, quanto oferece
sudo sensmos-store.py --pair 192.168.1.50 --pin 123456 --name "NAS na cave" \
--dir /srv/sensmos-store --capacity 100G
# 3 — instalar e arrancar como serviço que sobrevive a reinícios
sudo sensmos-store.py --install-service
# 4 — acompanhar
journalctl -u sensmos-store -fO emparelhamento imprime OK — attachment …, token saved to /etc/sensmos-store.json. O registo do serviço mostra depois:
21:14:02 store agent store-py/0.1 dir=/srv/sensmos-store capacity=100 GB used=0.00 GB
21:14:03 connected as 3f9a1c2eA partir desse momento está no pool. O primeiro comprador aparece no registo como put 7d0b… 18.1 MB … seguido de put 7d0b… done, e as provas como proof 7d0b… block 3: answered (10 MB hashed).
O endereço do node na LAN está na lista de clientes do router; o PIN é o PIN do node na app. O node tem de estar online (ligado ao backend) no momento do emparelhamento — encaminha o seu pedido e a resposta do backend.
Como é pago
| o quê | condições |
|---|---|
| preço | 0,1 GALU por GB por cópia por dia — um pacote começa em 1 GB e cresce 1 GB de cada vez; 10 GB são 1 GALU por dia por cópia |
| a sua parte | 70%; 30% voltam ao pool de recompensas |
| pago por | cada dia em que o pacote de um comprador está fixo consigo e você esteve presente: com os ficheiros dele no seu disco, a sua cópia passou uma prova; enquanto o pacote ainda está vazio, o seu agente reportou nesse dia — o espaço está reservado de qualquer forma |
| não pago por | dias offline ou com prova falhada; dias em que o comprador não tinha GALU — esse dia conta como atraso para o comprador (envios pausados, cópias libertadas após 14 dias sem pagamento) e você não é pago por ele |
O acerto corre uma vez por hora no backend e regista cada (dia, comprador, vendedor) uma única vez. O GALU entra no saldo da sua carteira como qualquer outra receita de serviço.
Provas — como o backend sabe que ainda tem o ficheiro
Três vezes por dia por cópia, o backend escolhe um bloco aleatório de 10 MB de um ficheiro aleatório que guarda e envia um sal. O seu agente faz o hash do bloco com o sal e responde com 32 bytes — não se movem dados, do nosso lado não se calcula nada. Com duas cópias em dois vendedores, as duas respostas são comparadas entre si. Quando divergem, ou quando só uma cópia está online, o backend pede o bloco em bruto e confere-o com a lista de hashes que o comprador forneceu ao enviar.
Três provas falhadas seguidas e a cópia é marcada como descartada: acabam os desafios, acaba o pagamento. Não há outra penalização — simplesmente deixa de ganhar com ela.
Capacidade e como os vendedores são escolhidos
--capacityé o que oferece. Não é verificado — quem declara mais do que tem falha as provas e não ganha nada, e essa é toda a verificação.- O que conta é o espaço livre no livro do próprio backend (o que ele colocou consigo), não o que o seu agente reporta; o relatório de cinco em cinco minutos é informativo.
- O pacote de um comprador começa em 1 GB e cresce um gigabyte de cada vez nos mesmos vendedores, por isso cada gigabyte inteiro livre da sua oferta pode ser vendido.
- Os vendedores são ordenados por espaço livre; as duas cópias de um comprador vão sempre para dois donos diferentes e nunca para as máquinas do próprio comprador.
- Uma vez escolhido fica fixo: todos os ficheiros que esse comprador enviar daí em diante ficam consigo, e quando ele compra mais um gigabyte, tem de caber consigo. O pacote dele não se move sozinho para lado nenhum. O comprador pode fechá-lo a qualquer momento: os ficheiros dele são apagados do seu disco, o espaço fica livre de novo e os pagamentos terminam nesse dia.
Para mudar a oferta, edite capacity_b em /etc/sensmos-store.json e reinicie o serviço. Para deixar de vender, pare o serviço — sem provas as suas cópias são descartadas dentro de um dia e sai do pool; os blobs em --dir são seus para apagar.
Rede
O agente liga-se para fora a sensmos.com por TLS e mantém essa única ligação. Nenhuma porta de entrada, nenhum reencaminhamento, funciona atrás de CGNAT. Transferências, provas e eliminações chegam todas pela mesma ligação.
Onde vê isto
Hoje: no registo do serviço. A app ainda não mostra estatísticas do vendedor; está a ser construído, e esta página dirá quando existir.
Flags
| flag | significado |
|---|---|
--pair IP --pin PIN --name "…" | emparelhamento único através de um node |
--dir DIR | onde ficam os blobs (predefinição /var/lib/sensmos-store) |
--capacity 100G | espaço oferecido; sufixos M, G, T |
--install-service | copia para /usr/local/bin, escreve e ativa a unit do systemd |
--be URL | backend alternativo, para testes |
A unit que escreve:
# /etc/systemd/system/sensmos-store.service
[Unit]
Description=Sensmos store agent
After=network-online.target
Wants=network-online.target
[Service]
ExecStart=/usr/bin/python3 /usr/local/bin/sensmos-store.py
Restart=always
RestartSec=10
User=root
[Install]
WantedBy=multi-user.targetEmparelhamento — o token
O agente não tem credenciais próprias. Pede ao seu node (com o PIN do node, de dentro da LAN) que responda por ele; o node encaminha o pedido ao backend, e o backend emite um token com o âmbito store.serve — servir sessões Store, nada mais. O token fica em /etc/sensmos-store.json (modo 0600) e o agente renova-o sozinho. Um node pode responder por até quatro acessórios. O contrato completo está em Acessórios e a API EXT.
Atualizações
O agente nunca se atualiza sozinho: corre como root na sua LAN, e um servidor capaz de lhe enviar código seria uma porta para a sua rede. Para atualizar, repita o passo 1 e reinicie:
sudo curl -fsSL -o /usr/local/bin/sensmos-store.py https://sensmos.com/ext/sensmos-store.py
sudo systemctl restart sensmos-storePrimeiros tempos
O Store é novo. Durante os testes um pacote é uma cópia em vez de duas, e o pool é pequeno. O preço por cópia não muda quando a segunda cópia voltar. Se montar um vendedor e durante algum tempo não chegar nada, é o estado honesto da procura, não uma falha do seu lado — diga olá no Discord e dizemos-lhe como está o pool.