Written by Awportals.com

The Activeworlds proprietary technology consists of 2 servers (authentication and content), the browser and the SDK. Of these the Uniserver deals with authentication for all other aspects of the technology.

A universe server can be considered the licensing control hub for a particular universe, it maintains and provides interfaces to databases containing worlds, citizenships, telegrams, botgrams and top level ejections. In addition it also deals with authentication and tracking the mid-level world servers in order that it can direct users to them.

Citizenship Accounts

The Activeworlds technology uses two different forms of account identification; firstly the citizen number which is effectively an automatically incrementing number allocated on citizenship creation – it is this number that is used in permissions and building but is rarely used by the average user.

Secondly there is the citizen name, this is the display name of the citizenship however it is also the login name. While citizen names must be unique at any single point it is perfectly possible for citizens to change their login name - this means that when logging in to a citizenship using the login name and password there is no guarantee that the account that will be accessed is the same as the one accessed the day before using exactly the same details.

In addition to the account number, name and passwords, the universe server also stores the following on each citizenship:
- Privilege Password
- Email Address
- Bot Limit
- Homepage
- Comments
- Immigration Time and Expiry Time
- Last time logged in
- Last IP address
- If Enabled and having Beta or Trial Access
- If having Personal Avatars
- If having the ability to Telegram.

Of these the Bot limit, enabled status, beta, trial, PAV access and telegrams are only editable by the super-user. Universes will often charge excessive sums of money for these options – mainly the Bot limit and PAV access.

It is important to note that the following security weakness; both login and privilege passwords are stored in plain text and anyone with access to root privileges (covered below) can see them. It is for this reason that access to root privileges should be tightly controlled as any compromise would result in every citizen having to change its passwords – potentially hundreds of thousands of users.

Root Privileges – Super User

The Activeworlds Uniserver only has a single point of authority – the root citizenship. This is the first account created when a universe is created and possesses the citizen number 1. The root citizenship has near unlimited access and is the only thing capable of creating citizenships or worlds directly.

A certain limitation of the root user is that it does not have access to the administration options of the actual world server software itself as this requires a private password set by the world host.

Root users are also immune from ejection, banning and can access any world unless they have been prevented from doing so via low-level server-side restrictions such as by a firewall.

Authentication Methods

There are 4 ways of authenticating to the universe server: citizenship, privileges, tourist and sdk.

Citizenship authentication requires the current login name and its primary password and determines the avatars citizen number. It is this authentication that controls access to citizen options and telegrams but little else. By default this authentication also sets the privilege authentication to the same account number.

Privilege authentication requires the current login name and its privilege password; this determines the avatars privilege number which is all important in determining what rights a user has at any given time (for example: a user logging on to root privileges becomes the root super-user themselves). It is this form of authentication that allows users to share privileges and build together.

Tourist authentication is the un-registered mode, and may not be enabled in all universes. This authentication requires a unique tourist name (at the time of login) and an email address. This sets both citizen number and privilege number to zero. Tourists cannot carry out privilege authentication.

SDK authentication requires the citizen number and privilege password; this is the equivalent of privilege authentication except that as an SDK application does not have a citizen of its own only its avatar privilege number will be non-zero.


This article is part of a series, click here to see part 2.