MPID stands for “MaidSafe Public ID” so this RFC is meant to implement a messaging system that works at this level with your chosen public name.
Summary
This RFC outlines the system components and design for general communications infrastructure and security on the SAFE Network.
Rationale
A messaging system on the SAFE Network will obviously be useful. Over and above this, the proposed messaging system is secure and private without the possibility of snooping or tracking.
A large abuse of modern day digital communications is the ability of spammers and less than ethical marketing companies to flood the Internet with levels of unsolicited email to a level of circa 90%. This is a waste of bandwidth and a significant nuisance.
Supported Use-Cases
The system will support secure, private, bi-directional communications between pairs of Clients.
This topic is for everything related to this way of messaging and it’s API (RFC #43). Please create a separate topic for Apps and/or websites on SAFE that use messaging and/or chats without this RFC.
Thanks for bringing this to broader attention, @polpolrene.
Didn’t realize this had been sitting there on Github for some time. I don’t pretend to follow a lot of it, but fitting it into what I do know, it really helps flesh out the network ideation and where we’re going.
This is more a feature request and actually something, that’s now ordinary with messaging systems. Can I also make payments with the messaging system? For instance if I type in:
$5@dirvine would the messaging app understand that it has to send $5 worth of SAFEcoins to David?
First problem with this is what do you want? Are you after a multi-purpose system or a messaging system for the core-network? Messaging is a core component of SAFE and payments already have a core-component that will handle the transfer of coins.
Second problem, you now need the core-component to look at exchange rates.
From what I understand the core-component that transfers ownership of coins will be sending a message that coins were transferred to the account. Not the other way around. (not the message sends the coins, but the message informs that coins were sent)
I’m a simple consumer, so I can’t really assess what is possible code wise. For instance if you type:
12dbjeCcmbaC6hxTQYbPHGirtivvU757hy qr code in Wolfram Alpha, it knows that it should spit out a qr code of that bitcoin address. IMHO the SAFE Network is here to eat up the current internet, so we should duplicate things that work fabulous on the current internet.
Can’t this simply be done with api’s?
Messaging apps on the current internet are sending money, so maybe the messaging app/system is the wallet. If we don’t explore possibilities and only see things as problems, we’re limiting our creativity. Many things can be reverse engineered.
Then we write an APP to do that. Not a core-level protocol for that. If we tried to duplicate what the current internet can do with all the applications & websites by building them all into the core-protocol then you’d never fit the “node” code into any computer we currently have (even NSA’s claimed super dupper computer) That is why we have APPs
Even if you don’t understand code etc, you need to understand the divide between APPs and the core-program (protocol) since APPs are what you will be running to generate the graphics for a QR code.
No - Well it could but see above, where would you stop building in APP code into the core-protocol (api)
The core-protocols have to be lean-mean-small and fast or else we get something slower than a mechanical adding machine.
Yes - APPs
not core protocol.
No its messaging system, not APP. The messaging system sends these messages (small bits of information/data). The APPs process the messages. So a equivalent email APP would grab the messages of email type and present them to you. Perhaps similar to what they do for current email.
A payment APP would use the safecoin APIs to transfer coins. A wallet APP would read messages sent from the safecoin API telling the wallet that you received coins.
But by trying to do everything in the core-protcol is very much limiting the creativity to what can fit in the core code. (what can fit in memory)
By having separate APPs to do all the high level wondrous things we allow creation built on the building blocks of the protocol. Divide and conquer.
@neo Thanks for taking the time to explain it, even though my head hurts understanding it, it makes sense. The messaging system is one of the train tracks and the apps using it are the trains riding above that.
Although I see it as
the tracks are the hardware moving the physical data around (electronics/existing base internet)
the train is the protocols (SAFE code/protocols)
the APPs get/put the data from/to the trains (or send instructions) and do whatever wondrous things they want to.
