Introducing Ict 0.6 and Bridge.ixi

Today we have released version 0.6.0 of Ict. The major features are:

+ implement EEE (Environment Entity Effect) infrastructure to enable inter-ixi communication+ translate gossip listeners and gossip preprocessors to EEE to simplify IXI+ let modules offer their functionality through API (/getModuleResponse)+ allow module developers to add modules to Ict from loaded classes instead of having to load from a separate .jar file -> simplifies module development and testing+ increase efficiency by checking incoming bytes against known transactions to avoid decoding the same transaction multiple times (#51)+ hash gui_password before storing it in ict.cfg (#59)+ fix #53 (adding the same neighbor multiple times to ict.cfg)+ 5s timeout after submitting wrong password to GUI to prevent brute-force attacks

Ict 0.6 introducesEEE(Environment Entity Effect), a new concept that does two things at once:

• Minimizing IXI technically by replacing various specific infrastructures (addGossipListener, addGossipPreprocessor, …) with a single general solution (addListener)
• Extending IXI functionally by introducing Inter-IXI Communication

EEE streamlines all kinds of event-based architectures on top of IXI. Entities such as IXI modules can subscribe to Environments and will be notified about all Effects published to those environments by other entities. This enables IXI modules to subscribe to each other and effectively work together.

Not only does 0.6 introduce a way for modules to make their functionality available to other modules via EEE but also through the Ict API. The API route “/getModuleResponse” allows to send API requests to any installed module directly. Modules will no longer have to run their own API. This will increase the user experience significantly since users won‘t have to open separate ports for IXI modules (CHAT.ixi will utilize this new feature soon).

Yet 0.6 hasn’t forgotten about the developer side of IXI and enables “virtual module loading”, a way for module owners to test their modules during runtime, without having to compile their module into a .jar first.

Besides these convenience features, the efficiency of Ict 0.6 was further increased by checking the encoded bytes of incoming transactions against those of already known transactions. This prevents Ict from unnecessarily decoding the same transaction into trytes over and over again, when received from multiple neighbors.

Security has also been improved. Passwords in Ict 0.6 will now be hashed, and no longer stored as plain text in ict.cfg. Additionally a short timeout has been introduced when connecting to the API with an incorrect password, to prevent brute-forcing passwords.

Until recently, modules for the Iota Controlled agenT (Ict) had to be written in the same language as its core. However, the vision of theIOTA eXtension Interface (IXI) is to enable cross-language support; everyone should be able to write modules in their desired programming language. This is exactly what Bridge.ixi has solved. By giving everyone the opportunity to participate with their desired programming language, Bridge.ixi will have positive impact on the overall development.  

Bridge.ixi provides a socket mechanism to allow external modules interact with IXI. By participating in the Environment-Entity-Effect (EEE) infrastructure, interaction between modules is possible. Regardless of whether it is a bridge module or not, all modules can participate in the same way. By acting like a proxy, Bridge.ixi will forward external requests and return internal responses. As a high-speed I/O engine it handles requests asynchronous.

Bridge.ixi makes use of protocol buffers, an efficient, language-neutral mechanism for serializing structured data. With protobuf3, the following languages are supported: Java, Python, Objective-C, C++, Dart, Go, Ruby, C# and JavaScript. Third-party implementations are also available for C, Rust, Elixir, Haskell, Swift and many more.  

It’s pretty simple. After you have installed Bridge.ixi for your Ict, all you need to do is establish a tcp socket connection to the Bridge.ixi server running on port 7331. Once you have done this, you are able to send/receive protocol buffer messages. To get a better feeling for the protocol buffers, it is a good idea to take a look at the official protocol buffer guide and the available module example. If you need further assistance, we are happy to help you in the#ict-helpsection of Discord.  

https://github.com/iotaledger/ict/releases/tag/0.6
https://github.com/iotaledger/bridge.ixi