Does this client/launcher support messaging or is it strictly for file transfers?
Better question is there a list of the specs for this app of what it actually does?
Does this client/launcher support messaging or is it strictly for file transfers?
Better question is there a list of the specs for this app of what it actually does?
@dirvine Rest APIs are past, GraphQL is the future of APIs. MaidSafe must use GraphQL (http://graphql.org/) for APIs.
Maybe one day. Iām pretty sure that theyāre very much in the camp of āif we did every āmustā then weād launch in 2020.ā
That sounds interesting. You should build it.
One could argue that this is a ābasic utilityā of the Network, no? But what if I wanted to make a messaging app?
That is a good long-term view. While I can see the ease of bundling everything at first, a good end-game is to be able to compartmentalize everything eventually.
They said they are going to build the messaging protocol. No reason to build a messaging app.
People will want to build their own messaging apps with their own names and UI so I think itās good to have options and healthy competition to drive progress. That being said Iāll be using the built in messaging but it makes sense that people will want to develop their own
That is FaceBookās developed API set isnāt it? Designed for database style accesses, to fit their operations? Will it even cover the full range of operations/interfaces needed for protocol level interfaces, that safe has?
As someone said, if its important to you then you are free to create a RFC for its introduction.
Why MUST safe use any particular API. It is the interface so its one item that could be forked by another person/group and maintained to keep up with the SAFE code. That way the 2 interfaces are available. It should not affect any of the SAFE protocols or operations, so feel free to organise this. But I would not demand the devās do this since it is just one of many APIs that could be implemented, that is if it even has all the interfaces needed.
GraphQL is not just Facebook APIs for their own operations.
GraphQL is an specification for data access, developed and open sourced by Facebook. GraphQL offers huge improvements over REST APIs and Its all set to replace REST APIs. GraphQL can be used anywhere with any language. I would suggest the community to read about GraphQL in detail before posting comments and request @dirvine to explore the possibility of using GraphQL for MaidSafe APIs.
MaidSafe is a big dream and the future of internet. A team of highly skilled engineers are working really hard to make this dream a reality.
I can understand people are desperate to see some return on their Safe coins investment but we must not forced the core team to launch it today. I suggest the community to be patient and have faith in the core team. We must encourage the use of best tools available for MaidSafe. @dirvine made a brave and right decision when he switched to RUST Language in the middle of development.
Becauseā¦
Obviously GraphQL is not the first system to manage client-server interactions. In todayās world there are two dominant architectural styles for client-server interaction: REST and ad hoc endpoints.
REST, an acronym for Representational State Transfer, is an architectural style rather than a formal protocol. There is actually much debate about what exactly REST is and is not. We wish to avoid such debates. We are interested in the typical attributes of systems that self-identify as REST, rather than systems which are formally REST.
Objects in a typical REST system are addressable by URI and interacted with using verbs in the HTTP protocol. An HTTP GET to a particular URI fetches an object and returns a server-specified set of fields. An HTTP PUT edits an object; an HTTP DELETE deletes an object; and so on.
We believe there are a number of weakness in typical REST systems, ones that are particularly problematic in mobile applications:
- Fetching complicated object graphs require multiple round trips between the client and server to render single views. For mobile applications operating in variable network conditions, these multiple roundtrips are highly undesirable.
- Invariably fields and additional data are added to REST endpoints as the system requirements change. However, old clients also receive this additional data as well, because the data fetching specification is encoded on the server rather than the client. As result, these payloads tend to grow over time for all clients. When this becomes a problem for a system, one solution is to overlay a versioning system onto the REST endpoints. Versioning also complicates a server, and results in code duplication, spaghetti code, or a sophisticated, hand-rolled infrastructure to manage it. Another solution to limit over-fetching is to provide multiple views ā such as ācompactā vs āfullā ā of the same REST endpoint, however this coarse granularity often does not offer adequate flexibility.
- REST endpoints are usually weakly-typed and lack machine-readable metadata. While there is much debate about the merits of strong- versus weak-typing in distributed systems, we believe in strong typing because of the correctness guarantees and tooling opportunities it provides. Developers deal with systems that lack this metadata by inspecting frequently out-of-date documentation and then writing code against the documentation.
- Many of these attributes are linked to the fact that āREST is intended for long-lived network-based applications that span multiple organizationsā according to its inventor. This is not a requirement for APIs that serve a client app built within the same organization.
Nearly all externally facing REST APIs we know of trend or end up in these non-ideal states, as well as nearly all internal REST APIs. The consequences of opaqueness and over-fetching are more severe in internal APIs since their velocity of change and level of usage is almost always higher.
Because of multiple round-trips and over-fetching, applications built in the REST style inevitably end up building ad hoc endpoints that are superficially in the REST style. These actually couple the data to a particular view which explicitly violates one of RESTās major goals. Most REST systems of any complexity end up as a continuum of endpoints that span from ātraditionalā REST to ad hoc endpoints.
There is no way to do so currently and there is no such plan to implement a usable front-end at launch.
There is no GUI nor CLI - only the protocol (the API) which can be used in apps, not on its own.
Therefore, there is no ābuilt in messagingā service. Only the API.
So who is going to build SAFEMessage?
Oh for the love of toastā¦ *Throws a pillow at @smacz * Yes of course someone will build it. But Iām just wondering who. Iām anxious to get everything operational.
Well, why not have them (Maidsafe the company) include in in the Launcher?
Would it not be considered a ābasic utilityā?
Iām pretty sure a basic messaging app can be developed within an hour, quick and dirty style. It may very well be a part of Decorum.
@brian_s has proposed updates to the MPID-Messaging RFC in the last few days and he has also created MPID-Messaging JIRA tasks. So for the latest state of play these are good places to check out.
Are you sure about this? I thought this was part of the LifeStuff application. There have been changes related to LifeStuff but I donāt recall anyone saying MaidSafe were dropping messaging - itās a killer app! @Ross can you clarify, thanks.
No we are definitely releasing a messaging app. Initialy a POC type app, but a polished version will also be released. I am sure there will be others to, but we will release one, possibly tied into a wallet (high probability). Whether itās part of a lifestuff overall app, we have not decided, but there will also be a cross platform VFS file system app as well. These are both immediate apps, the wallet part very soon with safecoin going in core (in near future).
āā¦very soon with safecoin going in core (in near future).ā
Oh you tease David ;). I really am so excited. The messaging with wallet sounds brilliant. I canāt wait to use it!
This feels like front row seats to watch dominoes start falling everywhere. I feel very lucky to be here.
I think about SafeNet last thing before I drift off most nights and itās one of the first things I think about when I wake upā¦ Iām not even technically literate enough to understand half of what I read in the tech updates, but I canāt stop thinking about the things I do understand and their implications.
What have you done to me Davidā¦? lol. My wife says I sound like a broken record and itās getting very boring for her lol ;). Please get me something I can use soon so I can share it with and show everyone else what it might mean for them and the big picture for the dominionists of the world.
Love you and what you do David
/hippyhug and thanks for the 10 years, I think you spent them very wisely and I really appreciate what all of you have (almost) created