subtract-smiles

> Molerat specification says that the fragment part of the URL is included in the request. However, I think that the fragment part would be for the client's use only.

When designing that, it seemed simpler to allow the client and the server to manipulate the same URL data. It's not really necessary, and if the client omits the fragment from the request it shouldn't affect anything.

> the specification of Molerat is unclear if the length is mandatory or not.

In Molerat, it is mandatory. In future versions of the spec I will probably change that.

> Molerat doesn't seems to have a way to send data with file formats other than Molerat forms

I have not included that functionality in the alpha version of the spec, but I think it should be relatively simple to extend forms to support it. Something like instead of

  |Placeholder text|[id text]

  |Placeholder text|[id text text/plain]

  |Upload an image|[id other image/png]

> Molerat specification also doesn't seems to say if keys are case-sensitive or not

They are, I will make it more clear in the next version of the spec.

> It also seem strange to me ... that the "message" is used for purposes other than merely the message.

The message is modeled after the <META> field in Gemini. That being, that it can be exploited by the server to pass additional context to the client without having additional keys that the client must parse based on the response type.

> Molerat has a hash included in the response (although it is unclear if it is supposed to be mandatory or optional).

The hash is optional. It is intended to allow clients to perform aggressive caching if they so choose to. If a server is aware that a client supports it, the server can also use it to omit sending a response body entirely. I plan on adding a way for clients to optionally send a user-agent identifier to the server for cases like this.

> Molerat file format is more complicated than the others mentioned above

I aimed to create a markup language that was relatively simple to learn but expressive enough to allow a high ceiling of content variety- something beginner friendly that still allows for more competent authors to design what they have in mind.

> It seems to be a superset of the features of Gemini

mtxt is heavily inspired by both gemtext and markdown.

> The example Molerat request in bash is wrong.

Thanks for pointing that out, I'll make sure to fix it in the next version.

> MacWright's suggestions about a clean start for the web has three rules

I had not seen that article before, thanks for referring me to it. I agree that Molerat doesn't quite meet all three rules, but I am more interested in seeing Molerat live alongside the modern web anyways as a place to host blogs, documentation, and simple feeds (mailing list archives, microblogging platforms, etc.).

The specification is currently written in Markdown, I plan to rewrite it in mtxt once I get a good parser completed. mtxt is designed so that reading it as an ASCII plain text document does not lose or significantly obfuscate any meaning.