To be fair, it only failed for people that relied on hosted services they trust instead of setting up a trust-less environment by themselves (what every professional app developer should do). Nevertheless, developers who learn and haven’t reached a professional level yet to self host all the things will judge aeternity on reliable hosted services (therefore i agree, i think it is very important to provide a reliable testing environment with hosted services for developers right now).
4 Likes
@nikitafuchs.chain I will hopefully start on this soon (this week)
First goal is to have ability to construct calldata directly in JS, via WASM.
That could help to get the ball rolling a bit.
1 Like
Does a problem about this issue is because Aeternity VM is not programming language agnostic (so relying on Erlang and it’s BEAM too much)? If so, that problem will occur if there will be a need to create alternative Aeternity nodes for example in GO or JAVA language. Ethereum has many protocol implementation in many programming languages and it’s protocol doesn’t rely on any particular language, it is language agnostic and the basics are clear enough to implement the interactions with contracts in any lang.
That flaw would be immediately recognized if for example the Aeternity protocol would be implemented in two inherently different languages in parallel from the beginning, for example Erlang and Go or Java instead of choosing Erlang and Elixir which both relies on BEAM.
We just discussing about this with @ae-omar yesterday.
First, I also agree the compiler is a temporary solution.
Implementing the encoding/decoding per SDK means maintaining lots of sdks.
Since aeternity and the compiler are both created in erlang, what about separate the encoding/decoding part into a library, and include it in both, the compiler and the aeternity node. Then, create a new set of v2 endpoints, that encodes and decodes the calldata in the node.
That will fix the actual problem, and also, easier to maintain.
First this one. Yes, it will be very important to have different implementations of the aeternity node in the future. Right now the core team is working in such a high pace, that it would be impossible for anyone to catch up.
If this slows down a bit, creating alternative implementations will get easier and if it happens, it will make the whole Blockchain more robust.
It is also not only about bugs in the protocol but also potentially in the erlang/beam itself. Luckily Erlang is a very reliable piece of software though 
A part of this is also “bringing aeternity to mobile” or parts of it, like the compiler or the VM. It is not necessary to have a full node with all it’s features everywhere, that would be overkill for many simple use cases.
Hi, it is impossible to maintain and provide SDKs for every language. That will not happen. Most of the resources are currently towards JavaScript and Python. Go and Elixir very small projects / teams.
Your suggestion already gets discussed. Looking at my previous answer we need to decide on a few feasible solutions that later can also be maintained “easily”. Some parts will always be behind and won’t provide all functionality.
The compiler is already seperated from the aeternity node. Overall the whole architecture is quite modular and components are well seperated from each other. The major challenge is bringing this to mobile / client side IMHO.
Also agree to this a lot. Looking at other projects and blockchains, everyone I see is using trusted services somewhere in their stack an that is totally fine.
The important thing here is beeing able to verify, if you don’t trust.
Transparency is more important than full trustless decentralization.
I expect a future where Blockchain aepps have millions of users, maybe 99% trust hosted services like a hosted node, a backend API server like the middleware or a hosted compiler.
1% though will run all the infrastructure themselves and if they spot a flaw or misbehaviour they will report it to the community and userbase.
A business that cheats it’s users will loose reputation and it will be easy to prove that they are not trust worthy.
Today in Bitcoin, 99% are using trusted nodes. It’s exactly the same. Using your samurai or ledger wallet but not connecting it to your own node at home will put you into the position that you need to trust that node.
Important is, that every major module is open source, well documented and easy to host. If this is given, there will be always someone invested who will do checks.
Great user experience is as important as being fully trustless. I would even say it’s more important.
Well i hope this get resolved somehow and the core team have this in their sights.
Since a native node on mobile is not in the immediate road map.
The issue with the compiler requirement by mobile apps is not a good solution, it multiplies almost by 3 every smart contract call, and on a mobiles platform that means latency issues, delays for the user, and we’re multiplying by 3 the possibility of an error, one must remember that not everyone have perfect mobile connections…, just been in the states recently
1 Like
Everyone who wants to contribute solutions is welcome. And if there is a strong request or even signaling via the governance aepp or a majority group of Blockchain app developers that ask for a specific thing, it will be heard.
3 Likes