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?
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.
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)
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.
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.