Produce the relay peering launch film
Mantenedores costumam responder em até 1 dia
@Ferryx349 já está trabalhando nisso.
Desde 23/10/2026.
Avaliação
Esta issue ainda não foi avaliada.
Descrição
Goal
Produce a short launch film for relay peering (#931), in the style of the 3.3.0 release film (#812): ~40 seconds, scene-by-scene, one idea per scene. It ships with the peering release and lives on the marketing site like the previous films.
Angle: futures and jobs-to-be-done
Don't explain the protocol — sell what peering lets people do that they can't do today. Draft beats, in the futures frame:
- "Run a relay for your people, not the whole network." A community relay no longer has to ingest everything to feel complete — it peers for its scope and fetches the rest on demand.
- "Your archive is worth something now." Operators with deep history can sell feeds to other relays, settled in sats — completeness becomes a product, not a cost center.
- "Fast, everywhere." Cache peers holding only the last hour put the hot feed near readers, so small relays feel instant without owning the firehose.
- "Relays that only talk to relays." A backbone layer becomes possible: archives and caches as infrastructure, edges facing users — the network grows a middle.
The closing should land the inversion the feature makes: today every relay tries to be everything; with peering, each relay gets to be one thing well, and the network assembles the rest.
Production notes
- Match the format and art direction of the existing films: scene-by-scene copy doc first, then renders for review.
- Factual discipline (lesson from the 3.3.0 film): every on-screen claim must match the shipped protocol — terms are flat per period, never per-event; settlement is Lightning between relays; cache windows are operator-configured.
- The film is about a future the feature enables: frame it as what becomes possible, not as adoption that already exists. No invented operators, metrics, or network statistics.
- Copy approval before rendering, per the usual flow.
Acceptance
- Scene-by-scene copy drafted and approved
- Claims in the copy checked against the peering implementation as shipped (#932–#940)
- Render reviewed (layout/legibility pass, as with the 3.3.0 film)
- Final film published with the peering release / on the site
- Linguagem predominante
- TypeScript
- Estrelas
- 829
- Forks
- 234
- Merge médio
- 17h 40min
- PRs com merge (30d)
- 90
Preparar o ambiente
- Inclui um Dockerfile ou arquivo Docker Compose
- Tem um modelo de pull request
- Ler o guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de cameri/nostream
-
Website
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 84/100
Mantenedores costumam responder em até 1 dia
-
bug factory rewrite rust
Mantenedores costumam responder em até 1 dia
-
Mantenedores costumam responder em até 1 dia
-
Mantenedores costumam responder em até 1 dia
-
bug factory rewrite rust
Mantenedores costumam responder em até 1 dia
Todas as issues de cameri/nostream
Issues semelhantes
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 68/100
awesome-dsh-plugin/awesome-dsh-plugin#9184 ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 75/100
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 85/100
farion1231/cc-switch#8829 ·
Mantenedores costumam responder em até 1 dia
-
[core-client] Remove unused hand-maintained transport helpers after the definition-table cutoverAbertadoc-audit enhancement
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 88/100
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 85/100