Skip to content

Restore IAR support in Halcyon as an administrative recovery and safety mechanism (untested) #164

@sonjamichelle

Description

@sonjamichelle

Restore IAR support in Halcyon as an administrative recovery and safety mechanism (untested)
Context and intent

During recent work in my own Halcyon fork over the past month, I explored restoring IAR (Inventory Archive) support that was previously removed when InWorldz forked from OpenSim.

My understanding is that IAR support was stripped out largely as a precautionary response to intellectual property concerns. However, that decision appears to have been based on an invalid threat model:

IAR commands require console-level access

Running them inherently requires trusted administrative privileges

Any potential IP misuse would necessarily involve core staff or explicitly trusted operators, not end users

As such, removing IAR did not meaningfully reduce risk, but did remove an important administrative tool for backup, migration, and recovery.

I am not proposing this as a policy change. This issue exists to document the work done and to surface IAR restoration as an optional administrative capability, particularly valuable as a recovery mechanism.

All changes referenced below exist only in my Halcyon fork, on the verge-base-fixes branch.

Important disclaimer on testing and scope

To be explicit up front:

I am not running a live Halcyon grid

These changes are not validated in production

IAR restore and export paths have not been exercised on a live user inventory

This is not a pull request, intentionally

This issue is informational. The commits referenced below should be treated as candidate restoration work that warrants testing and validation by maintainers or operators running active Halcyon instances.

Why restoring IAR matters

Restoring IAR support provides several concrete benefits:

Administrative inventory backup and export

Offline inspection and archival of inventory state

Migration tooling for operators

A last-resort recovery path if inventory corruption occurs

Notably, this becomes especially relevant in the context of the separate issue documenting Firestorm-related inventory loss and protocol mismatches. If those fixes prove incomplete, incorrect, or environment-specific, IAR provides a way to recover or reconstruct affected inventories rather than treating loss as unrecoverable.

In other words, even if the inventory fixes are ultimately rejected, restoring IAR still adds real operational value.

Work performed

The goal of the work was restoration and documentation, not redesign.

Commit 1: Restore IAR interfaces and archiver wiring
8d89de5
Restore IAR interface/docs and wire archiver notes

Files touched:

InventoryArchiverModule.cs

IInventoryArchiverModule.cs

iar-notes.md

Verge-Changelog.md

Summary:

Restores the IAR interface surface that had been stripped

Reintroduces documentation notes describing intended behavior

Does not attempt to expand IAR scope beyond historical expectations

Commit 2: Add IAR support documentation
22d2617
Add Verge IAR support doc and update changelog

Files touched:

Verge-IAR-Support.md

Verge-Changelog.md

Summary:

Documents intended IAR usage

Clarifies administrative nature and expectations

Serves as operator-facing reference material

What this work does not attempt

To avoid ambiguity, this effort does not:

Enable IAR for end users

Add new inventory serialization formats

Bypass permission checks

Introduce automated or scheduled exports

Alter Halcyon’s trust or security model

It strictly restores administrative tooling that already existed upstream in OpenSim and was previously removed.

Why this is an issue and not a pull request

Because I do not operate a live Halcyon grid, I cannot responsibly assert that:

IAR exports are safe under current inventory semantics

Restore paths behave correctly under modern viewer interaction

Edge cases involving links, folders, or permissions are fully handled

Those validations require live testing by operators running real grids with real inventories.

This issue exists to document the work done and to give maintainers a concrete baseline should they choose to evaluate restoring IAR support.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions