In a federated scientific data management system, individual nodes serve as autonomous components that collectively form a distributed research infrastructure. Institutional Storage Gateway Nodes provide access to large-scale research repositories, exposing datasets while maintaining local security policies. Personal Research Nodes represent scientists' laptops or workstations that share specialized datasets, analysis tools, or computational resources directly from personal environments. Compute Cluster Gateway Nodes serve as entry points to high-performance computing resources, enabling remote access to parallel processing clusters or specialized facilities. Each node maintains its own security boundaries and governance while contributing to seamless cross-institutional resource and data sharing. A node can also perform several of these roles simultaneously, enabling advanced data orchestration strategies such as data-to-compute and compute-to-data in the network.

Because realms share the same cryptographic key, nodes participating in realms trust each other. This ensures that a set of defined Nodes uses the same policies for authorization, authentication, metadata handling and data replication. By default access relevant information is shared with every other node in a realm. Data and metadata can be replicated by default to nodes inside a realm, while manual replication is still possibly with other nodes from other realms, but without the guarantee to use the same access restrictions. This flexible approach guarantees a resilient data storage system, where data and metadata can be dynamically transferred. Policies can for example, define how access should be managed, how data should be replicated, which metadata standards need to be enforced or which fields need to be set on metadata, so that consistent metadata handling is ensured in a realm. Users that are registered in a realm can interact with other realms via the identity provider used by their home-realm, supporting interoperability between nodes and realms.

Groups are used to organize users and permissions and form the basis of access-control and permission management for resources. Users can be part of one or multiple groups and are added by group admins or can request access to specific groups. Every user can get assigned to one or more roles that represent permissions. These permissions can be assigned for example to only permit individual resources or allow only metdata or data management. This allows for a flexible, fine-grained authorization system.

The basis of metadata is the json-based RO-Crate standard. This means that every metadata object must adhere to the schema.org standard. These standards enable more flexiblity on nearly every point compared to version 2.

This for example allows for:

• One metadata definition collecting multiple data entries
• One metadata definition collection other metadata definitions
• Distributed linked metadata
• inclusion of descriptions for non-aruna metadata links

Collaborative editing of metadata is handled by CRDTs, allow for flexible asynchronous merging of changing actions. Every change results in a new version that gets collected in a version history. Each change not only includes the resulting action, but also the user that triggered the change, the node that executed the change and the realm where the action took place in. Because metadata can now contain metadata that is located at other nodes or even realms, the distribution of metadata and data becomes easier than before. This not only allows for much higher scaliblity than version 2, allowing for example the integration of massive databases inside the p2p-aruna system, but also giving researchers the possibility to store data on a resilient federated system.

Files can be uploaded independently of metadata creation via an s3 interface. Data can be located at nodes by its content hash, or by its s3 path. While s3 paths can change, content hashes cannot, allowing for pinning specific data versions via content hashes, while still allowing for flexiblity of paths via the s3 interface. Data can be stored in different data-backends, allowing for flexible deployment of nodes in vastly different environments. Not only newly created data can be stored on nodes, but also existing data on supported backends can be ingested to a node, allowing for data reuse and integration of existing data sources into aruna. Data can be replicated to other nodes via replication policies. Disclaimer: Filters in replication policies are currently ignored. If a complete bucket gets replicated, the associated paths and permissions are also replicated. If only some objects are replicated, they are only replicated by content hash, without their s3 paths. This means, that data can be accessed at any node by its content hashes, but only on some nodes by its s3 paths. Uploaded data can be linked to metadata objects, including their technical metadata. This allows for workflows to first create all neccessary data and load it into aruna, and then select only the neccessary data to be linked in one or more metadata objects.

Policies form the basis of autonomy for each resource and node. They define what needs to be done or what is permitted on specific resources and can be integrated on a resource, group, node or realm level. These form the building block of the different layers of trust inside a p2p network. Because different institutions or consortia have different constraints, a defined set of policies is defined for each realm. This can include replication policies for data or metadata and policies that deny for example specific actions for specific nodes. The resulting flexiblity allows for example differentiation between higher-trust nodes, included in access-constrained compute environments that still can participate in a realm and the p2p network. Programmatic definition allows for maximum flexibility at the definition level and ensures that even complex scenarios are covered.

With hooks users can define actions that can trigger task execution of external TES services. Within the p2p network, specific nodes can be associated with specific compute resources, that can automatically trigger workflow executions. This powerful integration can efficiently route workflow jobs to the nearest compute resource to allow for data-to-compute patterns. Each job can be enriched with metadata information coming from the triggering resource action, helping to not only enrich metadata and data with provencance information, but also helping workflows to carry metadata information to external services.

Similar to Arunas version 2, a website is planned to lower the entry barrier for participants in the p2p network. Each realm can also deploy custom services individually, which interacts with the API on behalf of the user, creating streamlined convenient interface to interact with realms. A local UI system is planned, similar to dropbox or torrenting managers, that help individual researchers to momentarily participate in the p2p network, to for example synchronize resources changes with remote nodes or share files with other individual researchers temporarily. To adress scripting and workflow execution, a CLI tool will be developed to help automate and script interactions with the p2p system.