Thanks to everyone who’s participated in the DataPaymentNet testnet. It has performed its role magnificently, telling us that the fundamentals of data payments are sound, even if the UX leaves a little to be desired still. We’ve lost a few nodes after a replication spike the community spotted last night. But we’ve still 1675 MaidSafe nodes happily trucking along (and pre-spike we were at 2001 nodes for much longer than prior).
We’ve taken note of the errors: zero chunks after several hours, small clients running out of resources when self encrypting large files, Network error could not retrieve the record after storing it, ConnectionClosed, Did not store all chunks of file, OutgoingConnectionError to PeerId and others. Some of these are related: zero chunks is probably something to do with OutgoingConnectionError and UnroutablePeer, where the node is not being added to peers’ routing tables. Others will be the result of changes to communications functionality elsewhere, and some will be bugs that were previously covered up but have now emerged from their holes as we’ve fixed issues. But don’t worry - we’re ploughing through them all. 
This week, following a question on this forum @Qi_ma explains a little about Records.
Records and how they relate to Chunks, Registers and DBCs.
Record is a libp2p feature that enables data upload to the network and retrieval from the network as required.
The Record encompasses various essential functions at the network level, including tasks such as identifying the closest peers and facilitating data transfer. By delegating these network-level responsibilities to the Record, we can concentrate more effectively on data payment, transfer validation, security check, etc.
As part of our current implementation, we have distinct data types based on specific user cases. Specifically, we have Chunk to handle immutable data, DBC to manage spends and Register for Conflict-Free Replicated Data Types (CRDTs). These data types represent the information intended to be shared among the participants of the Safe Network. All of these data types can be encapsulated within the Record structure, thus enabling us to leverage its powerful functionalities.
By employing the Record, we can effectively store and exchange our custom data types, thus fostering seamless data sharing within the Safe Network.
Related to this is RecordStore which is a libp2p module designed to facilitate efficient storage of records onto disk while also serving as an interface to enable the execution of customised data tasks, such as data payment processing, transfer validation, security checks, and others. The RecordStore effectively bridges the gap between these custom data operations and the native libp2p Record, enabling seamless interoperability and integration within the system.
General progress
@Bzee has been looking at the UnroutablePeer and OutgoingConnection errors, which are rare issues, but not rare enough to ignore and seem to be related to nodes being ignored by other peers. They may be the result of recent fixes by the libp2p team, so he is conferring with them. The AutoNAT NAT detection function is another place he and @Aed900 are looking.
@Joshuef is also digging in here, as well as into ‘RecordParsingFailed’ and the occasional memory spikes reported by @shu and other community members. 
@Qi_ma is leading investigations where our test setup can trigger a double spend on occasion, halting CI.
Meanwhile, on the internal testing front, @roland has fixed an infinite loop in the data verification process and @chriso continues to smooth the path to automated testnet deployment.
There have been discussions on how we can register as having a fixed address to ease several operations. Registers are mutable so their hash cannot be used as a network address, unlike, say, a Chunk. But there are ways around this, which @bochaco is spearheading.
@Anselme is preparing the ground, refactoring registers to remove type tags which are no longer needed
And looking a little further out @dirvine has been thinking about integrating SimpleX for DBC transfers and also the potential for local personal AIs to sit on the client and manage things like data storage, wallets and text-to-speech/speech-to-text for the user. There are lots of exciting things coming together in that area now, and Safe is in a great place to take advantage.
Useful Links
Feel free to reply below with links to translations of this dev update and moderators will add them here:
Russian ; 
German ; 
Spanish ; 
French; 
Bulgarian
As an open source project, we’re always looking for feedback, comments and community contributions - so don’t be shy, join in and let’s create the Safe Network together!
