MaidSafe Dev Update :safe: 19th January 2016

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?

1 Like

@dirvine Rest APIs are past, GraphQL is the future of APIs. MaidSafe must use GraphQL (http://graphql.org/) for APIs.

2 Likes

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.ā€

2 Likes

That sounds interesting. You should build it. :stuck_out_tongue:

1 Like

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.

2 Likes

They said they are going to build the messaging protocol. No reason to build a messaging app.

1 Like

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

2 Likes

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.

1 Like

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.

1 Like

So who is going to build SAFEMessage?

2 Likes

But who will build the roads?!

1 Like

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.

3 Likes

Well, why not have them (Maidsafe the company) include in in the Launcher?

Would it not be considered a ā€œbasic utilityā€?

2 Likes

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.

5 Likes

@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.

4 Likes

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.

4 Likes

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

25 Likes

ā€œā€¦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 :heart_eyes:

9 Likes