Can someone who's an actual developer chime in on this Nostr alternative storage proposal? I saw a post the other day of someone asking for storage alternatives that were not BLOSSOM and a couple of the responses were to just use CDNs but after watching the ridiculously boring presentation on Freenet it turns out the network itself can just store the data!🤯
#asknostr #nip #freenet #storage #FUTO#blossomI am seriously out of my depth here but damn it if it didnt sound like a plausible idea to improve Nostr in general due to the use of contracts etc so
@jb55 @Jeletor 🌀 @Vitor Pamplona @Derek Ross @franzap what say ye?
Sorry it's ai sloppy but it's better than anything I can verbalize with my barebones grasp of coding:
Here is a proposal for a NIP (Nostr Implementation Possibility) designed to bridge the gap between Nostr's speed and Freenet's permanence.
NIP-XX: Freenet (Locutus) Contract Backed Storage
* Draft: 1
* Author: Danielsan256 (LLM assisted duh)
* Status: Draft
Abstract
This NIP defines a standard method for Nostr events to reference Freenet (Locutus) Contracts as a decentralized backend for data persistence, heavy media storage, and censorship-resistant history archival. It allows Nostr relays to remain lightweight while offloading "heavy lifting" (video, high-res images, and deep history) to the Freenet swarm.
Motivation
Current Nostr relays struggle with two main limitations:
* Storage Costs: Relays often delete old events (GC) to save space, breaking long-term history.
* Media Centralization: Most "decentralized" Nostr clients still rely on centralized HTTP servers (AWS S3, imgur, or personal servers) for images/video.
Freenet (formerly Locutus) offers a decentralized key-value store where data is kept alive by the network's collective bandwidth. By linking Nostr events to Freenet Contracts, we create an "Immutable Backstop" for Nostr content.
Specification
1. The freenet Tag
We introduce a new tag "freenet" which can be added to any event. This tag contains the Freenet Contract Key (the address) where the data associated with this event lives.
["freenet", "<contract_address>", "<usage_hint>"]
* <contract_address>: The unique cryptographic address of the Freenet contract (WASM).
* <usage_hint>: A hint to the client on how to interpret the contract. Values:
* "media": The contract contains the binary data for an image/video attached to the note.
* "history": The contract contains the full event history of this conversation/thread.
* "relay": The contract is acting as a "virtual relay" state machine.
2. New Event Kind: 10060 (Freenet Storage Pointer)
A new event kind 10060 is defined to announce that a user is mirroring their content to Freenet.
Content:
The content field should be empty or contain a human-readable summary.
Tags:
* ["freenet", "<contract_key>", "archive"]: The Freenet contract where this user's entire event history is being synced.
* ["e", "<event_id>", "marker"]: (Optional) The last event ID successfully synced to Freenet.
Example Event:
{
"kind": 10060,
"pubkey": "a1b2c3...",
"content": "My full history is archived on Freenet.",
"tags": [
["freenet", "A8x9...zK2j", "archive"],
["p", "a1b2c3..."]
],
...
}
Client Behavior
Fallback Resolution (The "Ghost Relay")
When a client tries to fetch a thread or media file and receives a 404 or timeout from standard Nostr relays:
* The client checks the event for a ["freenet", ...] tag.
* If present, the client initializes a local Freenet node (or connects to a local gateway).
* The client subscribes to the Freenet Contract address.
* The Freenet network delivers the missing data (e.g., the old replies in a thread) directly to the client, bypassing the failed relay.
Media Embedding
For large files (Kind 1063 File Metadata), the client traditionally looks for a url tag. This NIP adds support for a freenet tag as a primary or fallback source.
{
"kind": 1063,
"content": "My new vlog",
"tags": [
["url", "
https://centralized-server.com/video.mp4"],
["freenet", "B7y8...9Lq1", "media"],
["m", "video/mp4"]
]
}
If the HTTP link dies (Link Rot), the client seamlessly pulls the video from the Freenet swarm.
Freenet Contract Logic (The "Bridge" Contract)
To support this NIP, a standard Freenet Contract (WASM) must be developed with the following logic:
* State: A Map<EventID, SignedEvent>.
* Update Rule: The contract accepts new data only if it is a valid, cryptographically signed Nostr event matching the pubkey of the contract owner.
* Conflict Resolution: Standard CRDT (Conflict-free Replicated Data Type) merging. If two peers offer different lists of events, the union of both lists is kept.
Use Case Example: The Unbannable Thread
* Alice posts a controversial opinion.
* She tags it with ["freenet", "ContractX", "history"].
* Relay A and Relay B delete her post due to pressure or censorship.
* Bob's Client sees the deletion but notes the freenet tag in the cached header.
* Bob's Client queries "ContractX" on the Freenet network.
* The Freenet swarm returns the full thread history. Alice has effectively "self-hosted" her thread on the decentralized web, independent of any relay operator.
Why this takes Nostr to the next level
* Solves "Link Rot": Nostr currently relies on HTTP for media. If the host stops paying the bill, the image vanishes. Freenet fixes this.
* True Censorship Resistance: Relays can block you, but they cannot block a Freenet contract without shutting down the internet.
* Reduced Relay Load: Relays can become "signaling servers" (just passing new messages), while heavy storage moves to Freenet.
