Undername support for Portal users

[tzarebczan]

We'll support a process for portal users to be able to grab an undername from our Portal ARNS. The AR.IO team is working on an enhancement to help with ownership of the ANT itself (so the user can own this and perform certain tasks): ar-io/discussions#6

The goal would be so that users who sign up have a nice url like tom_portal.arweave.net instead of having a long txid, or buying an ARNS up front.

We'll work on the messaging for this, but we would have control over who we approve, so we can potentially censor here since it's our ARNS. The next step would be for them to either not use an undername at all, or buy their own ARNS. Theoretically it should be possible for others to run their own top level Portal ARNS and do the same thing as we'd do, and for someone to move their ANT from one Portal to another.

This would probably be as part of some onboarding process during Portal creation, and it could be skipped. It can be triggered again from somewhere on the domains area. Since it will have to go through an approval process, they won't have it right away so we want to make sure that status is clear during this process.

• need to setup intermediary approval process to request these. This would be used to see what's available vs not
• want to probably allocate some for existing odysee channels / large creators - would be done in this same approval process.
• create a UI for portal arns controllers/owners to approve/deny requests. Also show all undernames (with ability to remove), manage undername increasing options, etc.
• support an option to preallocate undernames by address - we could use the current sign up to list gauge undername claiming, and then let those people use it right away without having to go through approval.

I'm sure this is missing some details, etc, can work through it as we go.

[bhavyagor12]

Overview

Its a Review Approval flow that allows admins to approve or reject requests for claiming undernames. The flow includes the following steps:

1. User submits a request to claim an undername.
2. Admin reviews the request and either approves or rejects it.
3. If approved, the undername is attached to the user's portal.
4. If rejected, the user is notified of the rejection.
5. The system logs the action for auditing purposes.

With this basic flow in mind, some additional considerations:

1. Maximum number of undernames a user can claim. (this could be a fixed number and admin should be able to change it)
2. Reserved undernames for certain users or groups (e.g., verified users, premium members) => map user address to a list of reserved undernames (admin can manage this list)
3. Undername format validation (e.g., no special characters, minimum/maximum length)
4. A Policy block that can have some admin rules / configs (maxPerAddr, requireApproval) => say initially admins want to allow everyone to directly claim

Roles

1. User: requests an undername.
2. Controller: reviews requests, approves/rejects, reserves names, changes policy.
3. Super Admin: Inits the process, can add / remove controllers

State

1. Owners: name -> ownerAddress (the source of truth for “taken”).
2. Reserved: name -> { to?: address, by, at }
   If to matches the requester, they auto-claim on request. (this is useful for users that have names reserved for them)
3. Requests: pending/approved/rejected/cancelled items with timestamps.
4. Policy: { maxPerAddr, requireApproval }.

Flow

1. UI will call the process to CheckAvailability(name) to see if the undername is available or not. (Before this do validations directly from ARNS)
2. If available, user can RequestUndername(name).
   • If reserved for them, it auto-claims.
   • If not reserved and requireApproval is false, it auto-claims.
   • Otherwise, it goes to pending state.
3. Controller view can see all pending requests.
   • Approve → assign ownership and clear any reservation.
   • Reject → store reason; user stays unassigned.
4. If name reserved / already taken - show try another name message.
5. User can CancelRequest(name) if pending.
6. User can ReleaseUndername(name) if owned.
7. If User hit cap → “per-address limit reached.”

Policy (Admin Config)

Allow for dynamic flags to be added so that the core flow can be adjusted without a lot of code changes.
Basic considerations here -

1. requireApproval:
   • true → all non-reserved requests go to review.
   • false → anyone can self-claim (still respects maxPerAddr).
2. Future-proof: add more flags without changing the flow.
3. maxPerAddr: cap on how many undernames one address can own (e.g., 1, 2, 4…).