Frequently Asked Questions

Why does Mim have GET and POST at the same time? Would the protocol not be simpler and more discoverable by browser if it was just GET requests?

A couple reasons. The first is that GET requests have a practical URL encoding size limits. If you end up requesting a couple hundred fingerprints, that link is going to be probably longer than what most systems can deal with, so it's not great for compatibility. You could have the filter on the GET request body, but that is a very blurry area of the HTTP spec, and is usually ignored by most HTTP servers.

The second is that GET requests get cached and saved. So there might be somebody saving the URL and hitting a very expensive query on your computer again and again by mistake.

The third is that it's a violation of the HTTP spec to make GET requests trigger a state change in the server. That's POST's job. That is why there are both GET and POST requests available.

Why is assigning license of communicated content to CC-BY-SA license required to use Mim Protocol?

This is done to protect the developers of the applications that use the Mim protocol. If that was not the case, your application would not be able to know the license of the content you are receiving from the network, and thus it would be unclear on whether it would be allowed to show the content to the end user of your application. By fixing the license to CC-BY-SA license for all content, your application always knows that it has a right to display the content it receives from the network.

This also allows your end user to freely modify, remix and redistribute the content he or she sees within the terms of the CC-BY-SA license, fostering a free and open environment.

Good to know

  • In Mim protocol, most objects are immutable. When they are emitted from a node and started to be distributed, there is no editing, deleting, or changing the object in any other way.
  • Since there is no such thing as delete, it is up to each client to decide how long they want to serve a post, or how long to keep it. For example, Aether, the reference client for Mim, keeps posts for 6 months, and then stops distributing them. It's a balance between storage needs and historical breadth.
  • Mim provides no guarantees that the data provided from the remote node is not malformed. Assume no trust on part of other nodes in actually conforming to the protocol. You should always be doing your own checksum to ensure integrity of the entity received.
  • The underlying protocol is HTTP over TCP. The format of the messages is JSON.
  • You should ignore the fields and objects you do not know how to read.
  • The order of field generation in entities should be ProofOfWork (over all except Signature, Fingerprint, anf itself), Signature (over all except Fingerprint, and itself), and finally Fingerprint (over all, except itself).
  • Good to know: an Unicode character is maximum 4 bytes, per RFC 3629.
  • The protocol only transmits text. You can expand image links inline in your application if you think it's a good security tradeoff to provide image / video or other types of rich media support. However the only actual data that is transmitted over the network is text.
  • All of the API responses are only available over HTTPS
  • All of the API responses will be gzipped in transport.