We recently had a discussion about the naming of our mailservers in #status-core channel. For a while now I’ve been saying that mailserver is a really bad name:
It’s not a server, it’s a Whisper node with history storage.
It’s not dealing with mail, it deals with whisper messages and envelopes.
The word mail evokes a technology from 1970s.
I liked the suggestion from @petty which was to rename them as a history node. Which describes its function much better, and matches the naming of a whisper node.
EDIT: I’d specifically like to hear from @jonathan and a marketing perspective.
I think this is a great suggestion. I dont think most people really understand how “mailservers” or no “history nodes” work in Status anyway so it is an opportunity for us to set the precedent and educate.
I personally love the name “history node”. Perhaps a blog post explaining how they work, why we use them, and why the term mail server is actually misleading?
Sure. From what I recall, mail server name came from Whisper v6 spec which specified history nodes and named them wrongly as “Mail clients” and “mail servers”. See EIP-627: Whisper Specification
In Status we have a mail system, which is the private message, but they are served by the same history nodes of the public chats.
See, this terminology was just used in an example of P2P Request/Message, in Whisper Spec (EIP-627).
Status Network is built in top of Whisper, which implements this P2P Request and Messages exactly as exemplified and used the example name.
OPTIONAL
P2P Request [ 126 , whisper_envelope ]
This packet contains two objects: integer message code (0x7E) followed by a single Whisper Envelope.
This packet is used for sending Dapp-level peer-to-peer requests, e.g. Whisper Mail Client requesting old messages from the Whisper Mail Server.
P2P Message [ 127 , whisper_envelope ]
This packet contains two objects: integer message code (0x7F) followed by a single Whisper Envelope.
This packet is used for sending the peer-to-peer messages, which are not supposed to be forwarded any further. E.g. it might be used by the Whisper Mail Server for delivery of old (expired) messages, which is otherwise not allowed.
I’m fine with us renaming it if a lot of people think it is useful.
I’m not sure we want to push them from a marketing point of view, considering we want to move away from that abstraction. I’d rather keep it low key until we have some better abstractions here (Swarm/Swarm-like, incentivization, use of remote log, individuals acting in this capability, etc)
fair enough. We should educate people on how the app works at the moment though. In reality it is part of the architecture, and people should understand how it works.
Hiding it because we will move away from it seem odd to me. Why not call attention to them, and highlight the fact that we want to improve Status by finding better solutions.
To be clear, I don’t mean hiding mailservers or how they work. But if we are going to do a rename as part of a rebranding and use it for marketing, then it seems to me like it’s something we are proud of, as opposed to lipstick on a pig. If we just want to explain it in docs thats cool.
I totally agree with @oskarth, I don’t like the idea of renaming them until they work differently. Currently the name is just as bad as the functionality so I like it.
My intention is mostly about reducing confusion for those who’d like to run one themselves. I recall people always insisting that we shouldn’t be running mailservers ourselves in a cluster but rather encouraging the community to run them, but now what I’m hearing from you is that we shouldn’t. Which one is it?
We should. That is largely a community effort and UX around installation/running process. While there have been isolated attempts no one has really pushed for these pigs to roam freely. That’s not the same thing as rebranding, putting a different color lipstick on the pig and marketing it as if we did any fundamental progress.
Everyone appears to agree that “Mailserver” is a bad name, and changing the name should happen at some point.
Arguments against changing the name today:
Changing the name would somehow communicate a major change / improvement in functionality.
Keeping the bad name is a motivator to improve the underlying functionality
We shouldn’t change the name until major changes have been implemented.
(implicitly) The public may judge us for changing the name without doing any work.
I want to change the name, I don’t really care about branding or marketability of the name. “Mailserver” is a poor descriptor for what is basically a message persistence / backup node.
We control the specs and should care that Waku communicates its features through clear concise terminology. “Mailserver” is fundamentally misleading terminology, that to me is enough of a reason to change the name.
If we want to introduce proposals for functionality improvements we can do so under the new name. If the public perception of changing the name is an issue just make it public that the name change is about making a correction to an error inherited from Whisper. Changes will be forthcoming.