1 month 1 week ago
If being cooped up has made you rethink your furniture, these sofas might help refresh your space.
Gear Team
1 month 1 week ago
Physicists have linked the “gravitational memory effect” to fundamental cosmic symmetries and a potential solution to the black hole information paradox.
Katie McCormick
1 month 1 week ago
Touchscreens just don't suit some games. Try one of these WIRED-tested smartphone controllers for your iPhone or Android instead.
Simon Hill, Louryn Strampe
1 month 1 week ago
“Smishing" is an attempt to collect logins or other sensitive information with a malicious text message—and it's on the rise.
David Nield
1 month 1 week ago
Amazon has six ebook readers. Here’s how they stack up—and which one might be right for you.
Medea Giordano, Gear Team
1 month 1 week ago
All eyes were on the Ever Given when it got stuck in the Suez Canal, but it’s not the only too-big boat for too-small ports—a problem for holiday deliveries.
Michael Waters
1 month 2 weeks ago
Plus: Bluetooth security, a Brazil hack, and more of the week's top security news.
Brian Barrett, Lily Hay Newman
1 month 2 weeks ago
These are our favorite portable speakers of all shapes and sizes, from clip-ons to a massive boom box.
Parker Hall, Jeffrey Van Camp
1 month 2 weeks ago
From bots that welcome new users to ones that keep spammers out, these tools help make your corner of the internet a fun, safe place to hang out.
Cecilia D'Anastasio, Eric Ravenscraft
1 month 2 weeks ago
Climate migration is already underway. Here's how cities can prepare.
Kate Yoder
1 month 2 weeks ago
There's still time to order a few games, accessories, and maybe even a TV before the holidays are over.
Eric Ravenscraft
1 month 2 weeks ago
RTS games used to dominate sales charts and spawn entire esports leagues. Can new entries bring the beloved genre back to life?
Luke Winkie
1 month 2 weeks ago
New York-based Daylight is rethinking fintech with a social twist.
Laura Miller
1 month 2 weeks ago
Treat the techie in your life to tomes revealing the inner workings of the companies and characters shaping big tech.
Simon Hill
1 month 2 weeks ago
The flaw in the logging framework has security teams scrambling to put in a fix.
Lily Hay Newman
1 month 2 weeks ago
Whether you’re skiing in the backcountry or trampolining in the backyard, we have an activity tracker for you.
Adrienne So
1 month 2 weeks ago
The play to put all Warner Bros. theatrical movies on the service in 2021 was a big gamble. It paid off.
Angela Watercutter
1 month 2 weeks ago
This “connected” update of the ever-popular multicooker is a winner, despite some shortcomings in its mobile app.
Joe Ray
1 month 2 weeks ago
Plus: The downfall of Yahoo and AOL, a look back at my career, and a concerning convergence in space.
Steven Levy
1 month 2 weeks ago
Researchers have long wanted to capture how protein structures contort in response to light. But getting a clear image was impossible—until now.
Karmela Padavic-Callaghan
1 month 2 weeks ago

Although we’re preparing for the Openfire 4.7.0 release, the recently discovered vulnerability in the Apache Log4j utility prompted us to push an immediate release of Openfire to address that issue. This release, Openfire 4.6.5, is available now.

We urge you to update as soon as possible. If that’s not feasible, then we advise you to apply the documented workaround (in the form of adding the following argument in the start script for Openfire: -Dlog4j2.formatMsgNoLookups=true) and/or look into applying other mitigating actions.

The process of upgrading is outlined in the Openfire upgrade guide. Please note that, if desired, a significant amount of professional partners is available that can provide commercial support.

You can find Openfire release artifacts on the download page. These are the the applicable sha256sums:

926e852abfe67970a4a64b7a58d16adbd3ae65269921288909d2a353457ac350 openfire-4.6.5-1.i686.rpm 5041fd66f5cf4642d25012642d827ad80c40057ba66f79aad04918edc94085ec openfire-4.6.5-1.noarch.rpm f1d7ed2d5d5bbd12c3af896329df48f97b73ae5435980b524248760a246552f6 openfire-4.6.5-1.x86_64.rpm da113f737514457209194024f57a90f52f499fefbf0a9eb3e3d888b24f214ece openfire_4.6.5_all.deb c16e13348767b489aef905d912eafca9650428af16a729b63a208fdbe97c9783 openfire_4_6_5_bundledJRE.exe e03cd4e5b2a76b203540580ca2714541ee86b1ef3b677d5c312d099567674f2d openfire_4_6_5_bundledJRE_x64.exe 28d628db9cce3cfb7acfa19977235b569729bcebff65a511dd882a4c1b554d6c openfire_4_6_5.dmg cb1c4a5f888cbeeb6bbfd29460c8095941cecddd8c5f03b3d3f1ca412a995e81 openfire_4_6_5.exe fcc3d45e9b80536b463fedbb959ff1e4f5fc5cef180502f6810c0f025a01f4ac openfire_4_6_5.tar.gz fe216d1eecb23050ebbf28f7afa8930ca167d99516051c3f5e03d545e183cf4c openfire_4_6_5_x64.exe fd0f853b249a8853da51b056f1e6b31d04c49763394321dbd60abb8cef9df940 openfire_4_6_5.zip

Apart from addressing the log4j issue, this release includes a small number of other modifications, as documented in the changelog.

We’re always happy to hear about your experiences, good or bad! Please consider dropping a note in the community forums or hang out with us in our web support groupchat.

For other release announcements and news follow us on Twitter

4 posts - 3 participants

Read full topic

1 month 2 weeks ago

This new ejabberd 21.12 release comes after five months of work, contains more than one hundred changes, many of them are major improvements or features, and several bug fixes.

When upgrading from previous versions, please notice: there’s a change in mod_register_web behaviour, and PosgreSQL database, please take a look if they affect your installation.

A more detailed explanation of those topics:

Optimized MucSub and Multicast processing

More efficient processing of MucSub and Multicast (XEP-0033) messages addressed to big number of addresses.

Support MUC Hats

MUC Hats (XEP-0317) defines a more extensible model for roles and affiliations in Multi-User Chat rooms. This protocol was deferred, but it is supported by several clients and servers. ejabberd’s implementation supports both the XEP schema, and also the Conversejs/Prosody custom schema.

New mod_conversejs

This module serves a simple page to allow the Converse.js XMPP web browser client connect to ejabberd. It can use ejabberd’s Websockets or BOSH (HTTP-Bind).

By default this module points to the public online client available at converse.js. Alternatively, you can download the client and host it locally with a configuration like this:

hosts: - localhost listen: - port: 5280 ip: "::" module: ejabberd_http tls: false request_handlers: /websocket: ejabberd_http_ws /conversejs: mod_conversejs /converse_files: mod_http_fileserver modules: mod_conversejs: websocket_url: "ws://localhost:5280/websocket" conversejs_script: "http://localhost:5280/converse_files/converse.min.js" conversejs_css: "http://localhost:5280/converse_files/converse.min.css" mod_http_fileserver: docroot: "/home/ejabberd/conversejs-9.0.0/package/dist" accesslog: "/var/log/ejabberd/fileserver-access.log" Many PubSub improvements

Add delete_old_pubsub_items command.
Add a command for keeping only the specified number of items on each node and removing all older items. This might be especially useful if nodes may be configured to have no ‘max_items’ limit.

Add delete_expired_pubsub_items command
Support XEP-0060’s pubsub#item_expire feature by adding a command for deleting expired PubSub items.

Fix get_max_items_node/1 specification
Make it explicit that the get_max_items_node/1 function returns ?MAXITEMS if the ‘max_items_node’ option isn’t specified. The function didn’t actually fall back to ‘undefined’ (but to the ‘max_items_node’ default; i.e., ?MAXITEMS) anyway. This change just clarifies the behavior and adjusts the function specification accordingly.

Improvements in the ejabberd Documentation web

Added many cross-links between modules, options, and specific sections.

Added a new API Tags page similar to “ejabberdctl help tags”.

Improved the API Reference page, so commands show the tags and the definer module.

Configuration changes

mod_register_web is now affected by the restrictions that you configure in mod_register (#3688).

mod_register gets a new option, allow_modules, to restrict what modules can register new accounts. This is useful if you want to allow only registration using mod_register_web, for example.

PosgreSQL changes

Added to PgSQL’s new schema missing SQL migration for table push_session (#3656)

Fixed in PgSQL’s new schema the vcard_search definition (#3695).
How to update an existing database:

ALTER TABLE vcard_search DROP CONSTRAINT vcard_search_pkey; ALTER TABLE vcard_search ADD PRIMARY KEY (server_host, lusername); Summary of changes: Commands
  • create_room_with_opts: Fixed when using SQL storage (#3700)

  • change_room_option: Add missing fields from config inside mod_muc_admin:change_options

  • piefxis: Fixed arguments of all commands

  • mod_caps: Don’t forget caps on XEP-0198 resumption

  • mod_conversejs: New module to serve a simple page for Converse.js

  • mod_http_upload_quota: Avoid ‘max_days’ race

  • mod_muc: Support MUC hats (XEP-0317, conversejs/prosody compatible)

  • mod_muc: Optimize MucSub processing

  • mod_muc: Fix exception in mucsub {un}subscription events multicast handler

  • mod_multicast: Improve and optimize multicast routing code

  • mod_offline: Allow storing non-composing x:events in offline

  • mod_ping: Send ping from server, not bare user JID (#3658)

  • mod_push: Fix handling of MUC/Sub messages (#3651)

  • mod_register: New allow_modules option to restrict registration modules

  • mod_register_web: Handle unknown host gracefully

  • mod_register_web: Use mod_register configured restrictions (#3688)

  • Add delete_expired_pubsub_items command

  • Add delete_old_pubsub_items command

  • Optimize publishing on large nodes (SQL)

  • Support unlimited number of items

  • Support ‘max_items=max’ node configuration (#3666)

  • Bump default value for ‘max_items’ limit from 10 to 1000 (#3652)

  • Use configured ‘max_items’ by default

  • node_flat: Avoid catch-all clauses for RSM

  • node_flat_sql: Avoid catch-all clauses for RSM

  • Use INSERT … ON CONFLICT in SQL_UPSERT for PostgreSQL >= 9.5

  • mod_mam export: assign MUC entries to the MUC service (#3680)

  • MySQL: Fix typo when creating index (#3654)

  • PgSQL: Add SASL auth support, PostgreSQL 14 (#3691)

  • PgSQL: Add missing SQL migration for table push_session (#3656)

  • PgSQL: Fix vcard_search definition in pgsql new schema (#3695)

  • captcha-ng.sh: “sort -R” command not POSIX, added “shuf” and “cat” as fallback (#3660)

  • Make s2s connection table cleanup more robust

  • Update export/import of scram password to XEP-0227 1.1 (#3676)

  • Update Jose to 1.11.1 (the last in hex.pm correctly versioned)

ejabberd 21.12 download & feedback

As usual, the release is tagged in the Git source code repository on Github.

The source package and binary installers are available at ejabberd XMPP & MQTT server download page.

If you suspect that you’ve found a bug, please search or fill a bug report on Github.

The post ejabberd 21.12 first appeared on ProcessOne.
Jérôme Sautret
1 month 2 weeks ago

This is the second part of our ‘Making Sense of Blockchain’ blog post series – you can read part 1 on ‘6 Blockchain Principles’ here. This article is based on the original post by Dominic Perini here.

Join our FinTech mailing list for more great content and industry and events news, sign up here >>

Theme II

Blockchain: Myths vs Realities

With so much hype surrounding blockchain, we separate the reality from the myths to ensure delivery of the ROI and competitive advantage that you need.

It’s not our aim here to discuss the data structure of blockchain itself, issues like those of transactions per second (TPS) or questions such as ‘what’s the best Merkle tree solution to adopt?’. Instead, we shall examine the state of maturity of blockchain technology and its alignment with the core principles that underpin a distributed ledger ecosystem.

7 Founding principles of blockchain

Blockchain technology aims to embrace the following high-level principles:

  • Immutability 
  • Decentralisation 
  • ‘Workable’ consensus
  • Distribution and resilience
  • Transactional automation (including ‘smart contracts’)
  • Transparency and Trust
  • A link to the external world

1. Immutability of history

In an ideal world it would be desirable to preserve an accurate historical trace of events, and make sure this trace does not deteriorate over time, whether through natural events, human error or by the intervention of fraudulent actors. Artefacts produced in the analogue world face alterations over time while in the digital world the quantized / binary nature of stored information provides the opportunity for continuous corrections to prevent deterioration that might occur over time.

Writing an immutable blockchain aims to retain a digital history that cannot be altered over time. This is particularly useful when it comes to assessing the ownership or the authenticity of an asset or to validate one or more transactions.

We should note that, on top of the inherent immutability of a well-designed and implemented blockchain, hashing algorithms provide a means to encode the information that gets written in the history so that the capacity to verify a trace/transaction can only be performed by actors possessing sufficient data to compute the one-way cascaded encoding/encryption. This is typically implemented on top of Merkle trees where hashes of concatenated hashes are computed.

Legitimate questions can be raised about the guarantees for indefinitely storing an immutable data structure:

  • If this is an indefinitely growing history, where can it be stored once it grows beyond the capacity of the ledgers?
  • As the history size grows (and/or the computing power needed to validate further transactions increases) this reduces the number of potential participants in the ecosystem, leading to a de facto loss of decentralisation. At what point does this concentration of ‘power’ create concerns?
  • How does verification performance deteriorate as the history grows?
  • How does it deteriorate when a lot of data gets written on it concurrently by users?
  • How long is the segment of data that you replicate on each ledger node?
  • How much network traffic would such replication generate?
  • How much history is needed to be able to compute a new transaction?
  • What compromises need to be made on linearisation of the history, replication of the information, capacity to recover from anomalies and TPS throughput?

Further to the above questions, how many replicas converging to a specific history (i.e. consensus) are needed for it to carry on existing? And in particular:

  • Can a fragmented network carry on writing to their known history?
  • Is an approach designed to ‘heal’ any discrepancies in the immutable history of transactions by rewarding the longest fork, fair and efficient?
  • Are the deterrents strong enough to prevent a group of ledgers forming their own fork that eventually reaches wider adoption?

Furthermore, a new requirement to comply with the General Data Protection Regulations (GDPR) in Europe and ‘the right to be forgotten’ introduces new challenges to the perspective of keeping permanent and immutable traces indefinitely. This is important because fines for breaches of GDPR are potentially very severe. The solutions introduced so far effectively aim at anonymising the information that enters the immutable on-chain storage process, while sensitive information is stored separately in support databases where this information can be deleted if required. None of these approaches has yet been tested by the courts. 

The challenging aspect here is to decide upfront what is considered sensitive and what can safely be placed on the immutable history. A wrong choice can backfire at a later stage in the event that any involved actor manages to extract or trace sensitive information through the immutable history.

Immutability represents one of the fundamental principles that motivate the research into blockchain technology, both private and public. The solutions explored so far have managed to provide a satisfactory response to the market needs via the introduction of history linearisation techniques, one-way hashing encryptions, merkle trees and off-chain storage, although the linearity of the immutable history comes at a cost (notably transaction volume).

2. Decentralisation of control

One of the reactions following the 2008 global financial crisis was against over-centralisation. This led to the exploration of various decentralised mechanisms. The proposition that individuals would like to enjoy the freedom to be independent of a central authority gained in popularity. Self-determination, democratic fairness and heterogeneity as a form of wealth are among the dominant values broadly recognised in Western (and, increasingly, non-Western) society. These values added weight to the movement that introducing decentralisation in a system is positive.

With full decentralisation, there is no central authority to resolve potential transactional issues for us. Traditional, centralised systems have well developed anti-fraud and asset recovery mechanisms which people have become used to. Using new, decentralised technology places a far greater responsibility on the user if they are to receive all of the benefits of the technology, forcing them to take additional precautions when it comes to handling and storing their digital assets.

There’s no point having an ultra-secure blockchain if one then hands over one’s wallet private key to an intermediary whose security is lax: it’s like having the most secure safe in the world then writing the combination on a whiteboard in the same room.

Is the increased level of personal responsibility that goes with the proper implementation of a secure blockchain a price that users are willing to pay? Or, will they trade off some security in exchange for ease of use (and, by definition, more centralisation)? 

3. Consensus

The consistent push towards decentralised forms of control and responsibility has brought to light the fundamental requirement to validate transactions without a central authority; known as the ‘consensus’ problem. Several approaches have grown out of the blockchain industry, some competing and some complementary.

There has also been a significant focus on the concept of governance within a blockchain ecosystem. This concerns the need to regulate the rates at which new blocks are added to the chain and the associated rewards for miners (in the case of blockchains using proof of work (POW) consensus methodologies). More generally, it is important to create incentives and deterrent mechanisms whereby interested actors contribute positively to the healthy continuation of chain growth.

Besides serving as an economic deterrent against denial of service and spam attacks, POW approaches are amongst the first attempts to automatically work out, via the use of computational power, which ledgers/actors have the authority to create/mine new blocks. Other similar approaches (proof of space, proof of bandwidth etc) followed, however, they all suffer from exposure to deviations from the intended fair distribution of control. Wealthy participants can, in fact, exploit these approaches to gain an advantage via purchasing high performance (CPU / memory / network bandwidth) dedicated hardware in large quantities and operating it in jurisdictions where electricity is relatively cheap. This results in overtaking the competition to obtain the reward, and the authority to mine new blocks, which has the inherent effect of centralising the control. Also, the huge energy consumption that comes with the inefficient nature of the competitive race to mine new blocks in POW consensus mechanisms has raised concerns about its environmental impact and economic sustainability.

Proof of Stake (POS) and Proof of Importance (POI) are among the ideas introduced to drive consensus via the use of more social parameters, rather than computing resources. These two approaches link the authority to the accumulated digital asset/currency wealth or the measured productivity of the involved participants. Implementing POS and POI mechanisms, whilst guarding against the concentration of power/wealth, poses not insubstantial challenges for their architects and developers.

More recently, semi-automatic approaches, driven by a human-curated group of ledgers, are putting in place solutions to overcome the limitations and arguable fairness of the above strategies. The Delegated Proof of Stake (DPOS) and Proof of Authority (POA) methods promise higher throughput and lower energy consumption, while the human element can ensure a more adaptive and flexible response to potential deviations caused by malicious actors attempting to exploit a vulnerability in the system.

4. Distribution and resilience

Apart from a decentralising authority, control and governance, blockchain solutions typically embrace a distributed peer to peer (P2P) design paradigm. This preference is motivated by the inherent resilience and flexibility that these types of networks have introduced and demonstrated, particularly in the context of file and data sharing.

A centralised network, typical of mainframes and centralised services is clearly exposed to a ‘single point of failure’ vulnerability as the operations are always routed towards a central node. In the event that the central node breaks down or is congested, all the other nodes will be affected by disruptions.

Decentralised and distributed networks attempt to reduce the detrimental effects that issues occurring on a node might trigger on other nodes. In a decentralised network, the failure of a node can still affect several neighbouring nodes that rely on it to carry out their operations. In a distributed network the idea is that the failure of a single node should not impact significantly any other node. In fact, even when one preferential/optimal route in the network becomes congested or breaks down entirely, a message can reach the destination via an alternative route. This greatly increases the chance of keeping a service available in the event of failure or malicious attacks such as a denial of service (DOS) attack.

Blockchain networks where a distributed topology is combined with a high redundancy of ledgers backing a history have occasionally been declared ‘unhackable’ by enthusiasts or, as some more prudent debaters say, ‘difficult to hack’. There is truth in this, especially when it comes to very large networks such as that of Bitcoin. In such a highly distributed network, the resources needed to generate a significant disruption are very high, which not only delivers on the resilience requirement but also works as a deterrent against malicious attacks (principally because the cost of conducting a successful malicious attack becomes prohibitive).

Although a distributed topology can provide an effective response to failures or traffic spikes, you need to be aware that delivering resilience against prolonged over-capacity demands or malicious attacks requires adequate adapting mechanisms. While the Bitcoin network is well positioned, as it currently benefits from a high capacity condition (due to the historical high incentive to purchase hardware by third-party miners), this is not the case for other emerging networks as they grow in popularity. This is where novel instruments, capable of delivering preemptive adaptation combined with back pressure throttling applied to the P2P level, can be of great value.

Distributed systems are not new and, whilst they provide highly robust solutions to many enterprise and governmental problems, they are subject to the laws of physics and require their architects to consider the trade-offs that need to be made in their design and implementation (e.g. consistency vs availability).

5. Automation

In order to sustain a coherent, fair and consistent blockchain and surrounding ecosystem, a high degree of automation is required. Existing areas with a high demand for automation include those common to most distributed systems. For instance; deployment, elastic topologies, monitoring, recovery from anomalies, testing, continuous integration, and continuous delivery. In the context of blockchains, these represent well-established IT engineering practices. Additionally, there is a creative R&D effort to automate the interactions required to handle assets, computational resources and users across a range of new problem spaces (e.g. logistics, digital asset creation and trading).

The trend of social interactions has seen a significant shift towards scripting for transactional operations. This is where smart contracts and constrained virtual machine (VM) interpreters have emerged – an effort pioneered by the Ethereum project.

The ability to define how to operate an asset exchange, by which conditions and actioned following which triggers, has attracted many blockchain enthusiasts. Some of the most common applications of smart contracts involve lotteries, trade of digital assets and derivative trading. While there is clearly exciting potential unleashed by the introduction of smart contracts, it is also true that it is still an area with a high entry barrier. Only skilled developers that are willing to invest time in learning Domain Specific Languages (DSL) have access to the actual creation and modification of these contracts.

The challenge is to respond to safety and security concerns when smart contracts are applied to edge case scenarios that deviate from the ‘happy path’. If badly-designed contracts cannot properly rollback or undo a miscarried transaction, their execution might lead to assets being lost or erroneously handed over to unwanted receivers.

Another area in high need for automation is governance. Any blockchain ecosystem of users and computing resources requires periodic configurations of the parameters to carry on operating coherently and consensually. This results in a complex exercise of tuning for incentives and deterrents to guarantee the fulfilment of ambitious collaborative and decentralised goals. The newly emerging field of ‘blockchain economics’ (combining economics; game theory; social science and other disciplines) remains in its infancy.

Clearly, the removal of a central ruling authority produces a vacuum that needs to be filled by an adequate decision-making body, which is typically supplied with automation that maintains a combination of static and dynamic configuration settings. Those consensus solutions referred to earlier which use computational resources or social stackable assets to assign the authority, not only to produce blocks but also to steer the variable part of governance, have succeeded in filling the decision making gap in a fair and automated way. Successively, the exploitation of flaws in the static element of governance has hindered the success of these models. This has contributed to the rise in popularity of curated approaches such as POA or DPOS, which not only bring back a centralised control but also reduce the automation of governance.

We expect this to be one of the major areas where blockchain has to evolve in order to succeed in getting widespread market adoption.

6. Transparency and Trust

In order to produce the desired audience engagement for blockchain and eventual mass adoption and success, consensus and governance mechanisms need to operate transparently. Users need to know who has access to what data so that they can decide what can be stored and possibly shared on-chain. These are the contractual terms by which users agree to share their data. As previously discussed users might be required to exercise the right for their data to be deleted, which typically is a feature delivered via auxiliary, ‘off-chain’ databases. In contrast, only hashed information, effectively devoid of its meaning, is preserved permanently on-chain.

Given the immutable nature of the chain history, it is important to decide upfront what data should be permanently written on-chain and what gets written off-chain. The users should be made aware of what data gets stored on-chain and with whom it could potentially be shared. Changing access to on-chain data or deleting it goes against the fundamentals of immutability and therefore is almost impossible. Getting that decision wrong at the outset can significantly affect the cost and usability (and therefore likely adoption) of the particular blockchain in question.

Besides transparency, trust is another critical feature that users legitimately seek. Trust has to go beyond the scope of the people involved as systems need to be trusted as well. Every static element, such as an encryption algorithm, the dependency on a library, or a fixed configuration, is potentially exposed to vulnerabilities.

7. Link to the external world

The attractive features that blockchain has brought to the internet market would be limited to handling digital assets unless there was a way to link information to the real world. It is safe to say that there would be less interest if we were to accept that a blockchain can only operate under the restrictive boundaries of the digital world, without connecting to the analog real world in which we live.

Technologies used to overcome these limitations including cyber-physical devices such as sensors for input and robotic activators for output, and in most circumstances, people and organisations. As we read through most blockchain white papers we occasionally come across the notion of the Oracle, which in short, is a way to name an input coming from a trusted external source that could potentially trigger/activate a sequence of transactions in a Smart Contract or which can otherwise be used to validate some information that cannot be validated within the blockchain itself.

Bitcoin and Ethereum, still the two dominant projects in the blockchain space are viewed by many investors as an opportunity to diversify a portfolio or speculate on the value of their respective cryptocurrency. The same applies to a wide range of other cryptocurrencies with the exception of fiat pegged currencies, most notably Tether, where the value is effectively bound to the US dollar. Conversions from one cryptocurrency to another and to/from fiat currencies are normally operated by exchanges on behalf of an investor. These are again peripheral services that serve as a link to the external physical world.

Besides oracles and cyber-physical links, interest is emerging in linking smart contracts together to deliver a comprehensive solution. Contracts could indeed operate in a cross-chain scenario to offer interoperability among a variety of digital assets and protocols. Although attempts to combine different protocols and approaches have emerged, this is still an area where further R&D is necessary in order to provide enough instruments and guarantees to developers and entrepreneurs. The challenge is to deliver cross-chain functionalities without the support of a central governing agency/body.

* originally published 2018 by Dominic Perini

For any business size in any industry, we’re ready to investigate, build and deploy your blockchain-based project on time and to budget.

Get in touch with your blockchain project queries general@erlang-solutions.com or via the contact us form.

The post Blockchain Tech Deep Dive 2/4 | Myths vs. Realities appeared first on Erlang Solutions.

Erlang Admin
1 month 2 weeks ago

After a long few months full of hard work, we are happy to tell you that we are close to a 4.7.0 release for Openfire!

This next version of our real time communications server has received a lot of improvements and bug fixes.

A key area of the code that has received updates is the Multi-User Chat (MUC) implementation, with the objective of making that more stable in clustered environments. As always, but especially so if you’re making use of this functionality, we’d very much appreciate your feedback!

Together with this beta release, we’ve also released a new version of the Hazelcast plugin, which is the plugin that adds Clustering support to Openfire. This release, version 2.6.0, goes hand-in-hand with the Openfire 4.7.0 release: Version 2.6.0 of the Hazelcast plugin will not work prior to the 4.7.0 beta release, while Openfire 4.7.0 (beta) and later will require at least version 2.6.0 of the Hazelcast plugin to enable clustering.

We value your feedback!

All feedback that we receive based on this beta will help us to improve the non-beta release. Even if you test this beta and find no issues, that’d be helpful for us to know! Please leave your feedback as a comment to this blogpost, or create a posting in our community’s forum! If you want to chat with one of the developers, feel free to join the open_chat chatroom. We provide a web client with direct access, or you can join using your XMPP client of choice at open_chat@conference.igniterealtime.org.

The beta release of Openfire 4.7.0 is available at our downloads page for beta releases. You can download version 2.6.0 of the Hazelcast plugin from that plugin’s archive page.

The sha256sum values for the Openfire artifacts are listed below:

6cf4cc7a0a834b23cdea0ade198c724ee4f0be5560f1d16321414497c4f5903b openfire-4.7.0-0.2.beta.noarch.rpm ceee17f76d2645f2fcc29f5a84efbcc7fc376f7e01ef05ba28b65e850fff96f8 openfire_4.7.0.beta_all.deb 71e1a373420e048ee4c5921bcb54b4efa2357aaf9e57501284f20f0edeaa0428 openfire_4_7_0_beta.dmg 7d1f248e03c60dbb071eeee6abf671932c47e154fae888bee9293f875323fdd7 openfire_4_7_0_beta.exe 44bebac3da5f5d5d00270dcc303b34b6efce4c7c2bd1bfd4520827f6e8a58549 openfire_4_7_0_beta.tar.gz 72f1cd7dc2015ec70902b3b18a5248651a6e3091ba12ebf8d2767834b057c17f openfire_4_7_0_beta_x64.exe 76e4cf8da32b062ed719812792849bcfc475a22208e721a5f1b7dcddda45a4a4 openfire_4_7_0_beta.zip

Please note that starting with this release, a Java Runtime Environment is no longer distributed with Openfire.

Thank you for using Openfire!

For other release announcements and news follow us on Twitter

3 posts - 3 participants

Read full topic