MaidSafe Dev Update :safe: 19th January 2016

I think @feelz might have been referring to showing an example of how network dev and updates are managed by the community via road-map? How to best manage core updates to the network seems to be a popular topic and one I have not heard or seen a great POC on.

I’d been thinking about this recently and have had to draw some comparisons to Bitcoin.

Bitcoin uses the miners’ hashing power as votes - based on what they choose to run. As we’ve recently seen with the mass exodus of Core in favor of Classic, this is certainly a way to run.

However, the federated nature of mining is very scary when you realize that there may end up being maybe only three or four major mining pools who dictate which software to run.

Luckily, vaults have no such problems, as they are able to have a voice even if they utilized a decade or more old computer to store data. Also, the ranking system can give more established vaults a larger voice - useful if you consider that they are more invested into - and hopefully more knowledgeable about - the system than a newer vault would be.

However @feelz’ post was meant to be a jab. Read the corporate jargon BS that he humorously suggested:

C’mon, it’s the difference between having a thing, and having a thought. Right now there’s a thought. Cool. Good for them. Update us when it’s a thing.

Yes fair point, probably not the most assertive statement we have ever made. We are implementing a much more detailed roadmap and believe we have found a good way of displaying all this information at both a high level while also allowing the user to drill down into more detail. The intention is to implement a small section of the chart to make sure it works (POC) before implementing the rest. We’ll keep you updated with progress.

12 Likes

Can always wait every 2 weeks for an update if people are going to be jumpy about words on a monitor, shrug.

3 Likes

More explained here @whiteoutmashups :grinning:

Intention is certainly not that. We do understand the advantages of having a plugin based approach. Where the launcher would be the main application and the other bundles can be plugged in. This would make the updates lighter and you don`t have to update the entire application just for fixing a simple issue in a package. But at the same time, this level of flexibility can not be implemented in a very short cycle(2 weeks). It would be better to keep it simple for now and get the application out to help in testing the network. The quicker we start playing with the application we learn more about the practical problems (Hope things are smooth). Shorter cycles will be better to scale it up gradually.

We can split things as we progress.

This release will be a GUI based application.

16 Likes

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