Some of the examples describe behavior that is not yet implemented. Those examples are in red boxes like this one. They should be treated as an informal specification of how Mizu will behave once complete.

Streams

If all we’re doing is publishing structured data to a distributed hash table, we don’t need Mizu. We can already do all that and more with just IPFS.

What Mizu lets us do is run queries on that data, and present that data in a structured way, called Streams.

A stream is really nothing more than a packaged set of queries into the database, alongside metadata (like links to images, stylesheets, and other resources) that tell a Mizu client how to render the results of a query. This makes it extremely flexible.

The simplest stream contains messages published by just a single user: only messages signed by the person with the corresponding private key appear in the stream. But more complicated streams are possible, such as:

• A group of users, any of which can add stream content.
• A group of users that can add stream content, and a single moderator that can edit or redact stream content.
• A stream that combines multuple other streams
• A stream that applies a filter on another stream.
• A stream whose metadata describes an interface where users can publish their own messages that are included in the stream.

A stream is added just like any other piece of data in the system, by publishing a message to the network:

For a detailed example of stream syntax, check out our Query Tutorial and Stream Tutorial

Private Messages

You may want to use Mizu to organize data without making that data publicly available. This is possible and safe.

All content in Mizu has a URI, but that doesn’t mean that the content is globally accessible, or that it ever leaves your machine. Think of Google Docs. Have you ever tried to share a Google Doc with someone, only for them to get an error that they don’t have permission to view the document? The document had a URI that you shared, but the URI existing didn’t mean that your data was publicly visible. Mizu works the same way.

Private messages are accomplished via Client Configuration Queries, described in the next section.

Redactions, Blacklists, Privatelists, and Pinning

One of Mizu’s principles is: You, and only you, have control over the data on devices you own. Programs that can modify or delete data stored on your device without your knowledge or consent is a violation of this principle. You alone are empowered to control what data is (and isn’t!) on your device.

Once something exists on the public Internet, you should assume it’s there forever. But there’s still good reasons to want to remove content from your Stream. If some data is no longer needed to display your site, then removing it from your Stream can reduce the amount of storage required for subscribers to pin your Stream. Removing content from a Stream can also (but doesn’t have to) act as a form of redaction: a request that nodes should not retain the removed data and to not propagate that data to their peers. But you should always keep in mind that there’s no way to enforce what other people do on their machines: you can request that data be removed, but it’s up to the client running on that machine to decide to obey.

Likeiwse, there may be content on a stream that you don’t want to view, or that you don’t want to be stored on your local node, or that you want to avoid forwarding to other nodes. Mizu should empower you to make those kinds of decisions.

Mizu implements all of these with the use of special Client Configuration Queries. These are queries that exist on your client and act as filters: and messages that match these queries are subject to special behavior by the client. The different Client Configuration Queries are:

• Pins Filter: Messages that match this filter are “pinned” and will not be removed from local storage, even if the client is trying to recover storage space.
• Private Filter: Messages that match this filter are flagged by Mizu as belonging only to you. You can separately configure what kinds of requests will permit the client to respond with these messages, including no requests, meaning that the message will never leave your machine.
• Block Filter: Messages that match this filter are never returned as a result of a local request. (Useful for flagging content that you don’t wish to see, but you still want to help propogate.)
• Discard Filter: Messages that match this filter are never retained locally.

When you subscribe to a stream, that stream gets added as a Pins filter, guaranteeing that your local copy of the stream will persist. Streams can tag a subquery as a “redaction filter”. Adding a message reference to the redaction filter is how a publisher expresses content that they wish to be removed from the stream.

When subscribing to a stream that has a redaction filter, you’re prompted to choose how your client should handle messages that match the redaction filter. Your options are:

• Discard
• Unpin and don’t forward
• Don’t forward
• Unpin
• Do nothing