Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Some SOGS operators may want to setup a room on their SOGS which features one way style communication, these rooms allow moderators and administrators to update the room with new messages, but disallows unprivileged users to send new messages. These sorts of rooms can be useful for providing updates or information.
*Skip to step 3 if you already have a room and you are an administrator in that room*
Replace TOKEN with the address to use in the room URL (which must consist of ONLY lowercase letters, numbers, underscores, or dashes), replace NAME with the room name to display in Session and optionally replace DESCRIPTION with a short description of the topic of the room.
replacing TOKEN with the room token you created in step 1 and replacing ACCOUNTID with your own Account ID
There are 4 types of permission currently available in rooms
r = Read (ability to read messages)
w = Write (ability to write new messages)
u = Upload (ability to upload attachments, including files, voice notes, images and videos)
a = Access (ability to join the room)
When modifying these permissions changes will only apply to non admins/moderators, the default permissions in a room will be "rwua" for all users
To create a read only group we want to remove regular users ability to write and upload attachments, we can do this using the following command
This command will ensure read and access permissions are provided and remove write and upload permissions for regular users.
As the permission changes do not affect administrators and moderators, they will still be able to read, write and upload to the group. New Account ID's can be given write/upload access by making those Account ID's moderator or admin, this can be done directly in the Session Desktop client or via the CLI.
At its core, Session is built on the Oxen Service Node network, so it's important to understand how the Oxen network functions to support Session's mission of enabling decentralised anonymous communications.
Many projects have attempted to establish decentralised permission-less networks. These projects have often found themselves struggling with a ‘tragedy of the commons’ of sorts, wherein public servers, required for the operation of the network, are under-resourced and overused. This inadvertently causes the network to provide poor service to users, which discourages further use or expansion of the network.
Conversely, those projects which are able to create large, public permissionless networks find themselves constantly facing questions about the parties that contribute to running that infrastructure. This can be especially damaging when the operation of that infrastructure can adversely affect the privacy, security, or user experience of an application. For example, the Tor network faces constant questions about evidence of Sybil attacks from unknown parties attempting to run large sections of of the public routing network, which could be used to de-anonymise users .
Session seeks to avoid these issues through using a different type of public access network: a staked routing and storage network called the Oxen Service Node network. This network is based on the Oxen blockchain, which itself is based on the CryptoNote protocol. Through the integration of a blockchain network, Session creates a financial precondition for anyone wishing to host a server on the network (and thus participate in Session’s message storage and routing architecture).
Authorisation for a server to operate on the network is attained through the server operator conducting a special staking transaction, which requires that an operator provably lock an amount of Oxen cryptocurrency assigned to their node (previously, this staking requirement was algorithmically adjusted over time; it is now fixed at 15,000 $OXEN).
This staking system provides a defense against Sybil attacks by limiting attackers based on the amount of financial resources they have available. The staking system also achieves two other goals which further reduce the likelihood of a Sybil attack.
Firstly, the need for attackers to buy or control $OXEN to run service nodes creates a feedback loop of increasing price for anyone attempting to run large portions of the network. That is, as the attacker buys or acquires more $OXEN and locks it, removing it from the circulating supply, the supply of Oxen is decreased and the demand from the attacker must be sustained. This causes the price of any remaining Oxen to increase, furthering the feedback loop of increasing prices. Secondly, the staking system binds an attacker to their stake, meaning if they are found to be performing active attacks, the underlying value of their stake can sharply decline as users lose trust in the network, or could be destroyed or locked by the network, in any case increasing the attackers sunken costs.
The other main advantage of a staked blockchain network is that service nodes earn rewards for the work they do. Service nodes are rewarded with a portion of the block reward minted upon the creation of each new block. This system makes Session distinct from altruistic networks like Tor and I2P by providing an incentive linked directly with the performance of a service node. Honest node behaviour and the provision of a minimum standard of operation is ensured through a consensus-based testing suite. Misbehaving nodes face the threat of having their staked capital locked, while the previously-mentioned cryptocurrency rewards function as the positive incentive for nodes to behave honestly and provide at least a minimum standard of service to the network.
The other foundational component of Session is an onion routing protocol, referred to as onion requests, which enables Session clients to obfuscate their IP addresses by creating a 3-hop randomised path through the Oxen Service Node network. Onion requests use a straightforward onion routing protocol which successively encrypts each request for each of the three hops, ensuring the first service node only knows the IP address of the client and the IP address of the middle service node, the middle service node only knows the IP address of the first and last service nodes, and the last service node only knows the IP address of the middle service node and the final destination IP address for the request.
Each Session client establishes a path on start-up, and once established, all requests for messages, attachments and meta information are sent through this path. Session clients establish a path by selecting three random nodes from their service node list (see bootstrapping), which contains each service node’s IP address, storage server port, and X25519 key. Clients use this information to create an onion, with each layer being encrypted with the X25519 key of its respective service node. This onion is sent to the first service node’s storage server; this service node then decrypts its layer of the onion. When a service node unwraps a layer, the destination key for the next node is revealed. The first service node decrypts its layer and initialises a ZMQ connection with the specified downstream node. When the onion reaches the final node in the path, that node sends a path build success message backwards through the path, which indicates a successful path built upon its receipt by the client.
Upon receiving the path build success message, the client will encrypt their messages with the X25519 keys of the final destination, be that a service node, file server, open group server, or client. The client also includes an ephemeral X25519 key in their request. When the destination server or client receives the request, they decrypt it and generate a response. This response is then sent back down the previously-established path, encrypted for the initial sender’s (the client’s) ephemeral key, so that the client can decrypt the response upon receiving it.
Onion requests provide a straightforward anonymous networking layer, and the Oxen Service Node network provides an incentivised, self-regulating network of remote servers which provide bandwidth and storage space. A number of services have been built on this foundation in order to give Session features commonly expected of modern messaging applications.
Message storage is an essential feature for any chat application aiming to provide a good user experience. When a user sends a message, they expect the recipient to receive that message even if the recipient's device goes offline or is turned off after the message has been sent. Users also expect the user on the other end to receive the message when their device wakes up or reconnects from an offline state. Apps that run on decentralised networks typically cannot provide this experience, because of the lack of incentive structures and, consequently, the ephemeral nature of clients and servers on such a network. Session is able to provide message storage through the incentivised service node network and its usage of swarms.
Although the Oxen blockchain incentivises correct service node behaviour through rewards and punishments, these incentive models cannot prevent nodes going offline unexpectedly due to operator choice, software bugs, or data centre outages. Therefore, for redundancy, a secondary logical data storage layer must be built on top of the service node network to ensure reliable message storage and retrieval.
This secondary logical layer is created by replicating stored messages across small groupings of service nodes called swarms. The swarm a service node initially joins is determined at the time of that service node’s registration, with the service node having minimal influence over which swarm it joins. This protects against swarms being entirely made up of malicious or non-performant nodes, which is important to maintain the network’s self-regulating properties.
Composition of each swarm inevitably changes as the networks evolves: some nodes leave the network and the newly registered nodes take their place. If a swarm loses a large number of nodes it may additionally "steal" a node from some other, larger swarm. In the unlikely event that the network has no swarms to steal from (i.e., every swarm is at Nmin=5 nodes), the ‘starving’ swarm (a swarm with fewer than Nmin nodes) will be dissolved and its nodes will be redistributed among the remaining swarms. Conversely, when a large number of nodes enter the network that would oversaturate existing swarms (i.e., every swarm is already at max capacity Nmax=10), a new swarm is created from a random selection of Ntarget=7 excess nodes. Note that Nmin < Ntarget < Nmax to ensure that a newly generated swarm doesn’t get dissolved shortly after and that there is still room for growth.
The outcome of this algorithm is the creation and, when necessary, rebalancing of swarms of around Nmin–Nmax service nodes which store and serve Session clients’ messages. The goal of the swarm algorithm is to ensure that no swarm is controlled by a single entity and that the network is resilient enough to handle both small and large scale events where service nodes are no longer contactable, ensuring data integrity and privacy in both cases.
The following set of simple rules ensure that service nodes within swarms remain synchronised as the composition of swarms changes:
When a node joins a new swarm, existing swarm members recognise this and push the swarm’s data records to the new member. When a node leaves a swarm, its existing records can be safely erased, with the exception of when the node is migrating from a dissolving swarm. In this case, the migrating node determines the swarms responsible for its records and distributes them accordingly.
The majority of popular messaging applications require the user to register with an email or phone number in order to use the service. This provides some advantages, including account verification, for purposes of spam protection, and social network discoverability. However, such requirements also create some major privacy and security issues for users.
The use of a phone number as the basis for ownership of an identity key/long-term key pair weakens security against user accounts being compromised, such as in the cases of popular applications like Signal and WhatsApp. This weakness primarily stems from the fact that phone numbers are managed by centralised service providers (i.e. telecommunications service providers) who can circumvent user control, allowing these providers to assume direct control of specific users’ numbers. Widespread legislation already exists to compel service providers to take this kind of action. Additionally, methods such as SIM swapping attacks, service provider hacking, and phone number recycling can all be exploited by lower-level actors .
Signal and Whatsapp put forward varying degrees of protection against these types of attacks. Signal and WhatsApp both send a 'Safety numbers have changed' warning to a user's contacts if identity keys are changed. In practice, however, users rarely verify these details out-of-band .
Both Signal and WhatsApp also allow users to set a "registration PIN lock" . This protection means that an attacker (including a service provider or state-level actor) needs access to both the phone number and the registration PIN code to modify identity keys. However, this feature is off by default, difficult to find in the settings menu, and automatically disabled after periods of user inactivity. These factors all significantly reduce the efficacy of registration PIN locks as a protective measure against the security risks of phone number-linked accounts.
Using phone numbers as the basis for account registration also greatly weakens the privacy achievable by an average user. In most countries, users must provide personally identifiable information such as a passport, drivers' license or identity card to obtain a phone number — permanently mapping users’ identities to their phone numbers. These identity mappings are kept in private databases that can be queried by governments or the service providers that own them. There are also a number of web scrapers and indexers that automatically scrape phone numbers associated with individuals. These scrapers may target sources such as leaked databases, public social media profiles, and business phone numbers to link people to their phone numbers. Since the only method of initiating contact with a user in Signal, WhatsApp, or similar application is to know the user’s phone number, this immediately strips away user anonymity — a significant concern for whistleblowers, activists, protestors and other such users.
Account systems based on phone numbers also limit the potential for the establishment of multiple identities by a single user. These systems also prevent high-risk users without access to a phone number from accessing these services.
Session does not use email addresses or phone numbers as the basis of its account system. Instead, user identity is established through the generation of X25519 public-private key pairs. These key pairs are not required to be linked with any other identifier, and new key pairs can be generated on-device in seconds. This means that each key pair (and thus, each account) is pseudonymous, unless intentionally linked with an individual identity by the user through out-of-band activity.
Because Session does not have a central server to keep records of user identities, the commonly expected user experience of being able to recover or log back into an account using a username and password is not possible. Instead, users are prompted to write down their long-term private key (represented as a mnemonic seed, referred to within Session as a recovery phrase) upon account generation. A user can use this backup key to recover their account if their device is lost or destroyed, and the user's contacts will be able to continue contacting that same user account, rather than having to re-initiate contact with a new key.
How to install Session on Debian based Linux distributions
The ONS namespace is broken up into two distinct sections. One section is responsible for all Lokinet names, referred to as .loki names, and the other section is responsible for Wallet and Session usernames.
Each ONS name can resolve to a Session public key, Wallet address or .loki address. Session and Wallet names are within the same namespace. When purchasing a Session record, the Wallet record is automatically added to your possession. Lokinet names are in their own namespaces. For example, when purchasing ‘KeeJef’ in the Session namespace, you can assign a Session public key. Additionally you can update the wallet record under a 2nd transaction.
So when a user looks up ‘KeeJef’ they are returned both a Account ID and Wallet address:
It is also possible to purchase ‘KeeJef.loki’ in the Lokinet namespace that is unique from the Session and Wallet namespace.
Depending on which context the name is being used, the application will automatically use the relevant mapping.
Both namespaces (Session/Wallet and Lokinet) have restrictions on the characters allowed in a name. All names are case-insensitive.
For Session (or Wallet), the name has to:
start with an alphanumeric character or underscore
consist of alphanumeric, hyphens or underscores in between
end with an alphanumeric character or underscore
Users may register names with special characters or emojis by using the equivalent Punycode representation. The name must be at least 1 character long, and at most, 64 characters long.
For Lokinet, the domain must:
start with an alphanumeric character
contain alphanumeric characters or hyphens
The character before the domain suffix .loki must be alphanumeric followed by the suffix .loki. Users may register names with special characters or emojis by using the equivalent Punycode representation. The domain name must be at most 253 characters long, including the .loki suffix.
By default all mappings in the Session/Wallet namespace will be preserved forever. This is important to ensure that wallet mappings don't change when a user wants to send money to a name. The .loki namespace will have re-registration periods to deter domain squatting and release names if the keys that registered them are lost.
By default names are owned by the wallet address that purchased the name. However, names can also be purchased on behalf of another user. Up to 2 wallet addresses may be specified as the owners of a name. This means up to 2 wallets can update and or transfer ownership of the record.
Once a name it can be transferred to another user's Oxen wallet by specifying the address of that wallet and paying the standard transaction fee to transfer the ownership.
Updates to mappings can be made at any time by the owner, at the cost of the standard transaction fee to include the new mapping in the blockchain.
Initially, management of all owned names will be possible through the Oxen Desktop Wallet; however we aim to add functionality to register and manage names to Session clients directly in the future.
Names in the Session/Wallet namespace cost 7 $OXEN to register. We will try to update this cost per hardfork to continue targeting the $5-10 USD range.
It is up to each user to choose which information they map publicly. If you don’t want to map your Account ID or Wallet address to your real world identity you might want to choose a different alias instead of something related to your name. Basic encryption is employed to mask publicity of data on the surface level, but please do not rely on this for critical privacy requirements.
All wallet sub-addresses generated via account new are supported as owners.
ONS records stored in the blockchain undergo basic encryption and decryption to deter monitoring of the chain. This does not provide strong guarantees for privacy and should not be relied on for situations with critical privacy requirements.
At its core, a typical ONS record from the database looks like:
name_hashed
encrypted_value
register_height
owner
backup_owner
txid
prev_txid
register_height
more fields (implementation details, see oxen_name_system.h)
Of which the name_hashed and encrypted_value fields use some form of encryption or decryption.
name_hashedHuman readable name is hashed with blake2b with the following parameters
Key Length: 0 bytes
Hash Length: 32 bytes
Name hash converted to base64 for storage into the sqlite3 database (this provides optimal lexicographic lookup as a key).
encrypted_valueGenerate the secret key for decryption/encryption using the unhashed name with Argon2ID v1.3 and the following parameters as of Valiant Vidar v7.1.X
Iterations: 3
Memory: 268_435_456 bytes
Salt Length: 0 bytes
Key Length: 32 bytes
Decrypt/encrypt the value represented in binary with XSalsa20Poly1305 and the following parameters as of Valiant Vidar v7.1.X
Nonce: 0 bytes
In ONS, an owner of a record has the ability to update information about the record by making a transaction on the Oxen blockchain. Owners are specified when buying a record and in ONS we support 2 types. A standard Ed25519 keypair and an Oxen Wallet address.
By default, the wallet is configured to assign itself as the owner of the mapping when purchased.
ONS records can be updated by getting the owner of the record to generate a signature that authorises the protocol to update fields in the record.
The following fields can be updated in a record
Copy the fields to update into a buffer
Copy the TXID into the buffer that last updated the record (which can be retrieved by querying the mapping).
Hash the buffer with blake2b with the following parameters
Key Length: 0 bytes
Hash Length: 32 bytes
Sign the hashed buffer
If the current owner (or backup owner) is a wallet address, it must be signed with the current owner's (or backup owner's) wallet secret spend key.
If the current owner (or backup owner) is a ed25519 key, it must be signed with the current owner's (or backup owner's) ed25519 secret key.
Although service nodes have the ability to store data on behalf of clients, this responsibility only extends so far. Requiring service nodes to store attachments, which can easily be orders of magnitude larger than messages (and might need to be stored for longer periods of time) would place an undue burden on the service node network.
With this in mind, a logical solution is for Session to interface with an untrusted centralised server that stores data obliviously. As long as the central server cannot know the contents of files, or who is storing and requesting the files, this system does not cause any metadata leakage.
This is achieved by first padding each attachment to fit within a fixed number of constant sizes between 0 and 10 megabytes, then encrypting the attachment with a random symmetric AES key. The sender then uploads the encrypted file using an onion request. In response, the file server provides a link to the piece of content, returned via the onion request path.
Once the sender obtains this link, they then send a message to the recipient via an existing pairwise session. This message contains a link to the content, a hash of the content, and the decryption key. The recipient then uses an onion request to pull the encrypted attachment from the centralised file server and decrypt it locally using the decryption key provided by the sender. The recipient also checks the hash against the attachment, ensuring the file has not been modified in transit.
By default, all Session clients use a Session file server run by the Oxen Privacy Tech Foundation for attachment sending and storage. Since attachments are not considered a core feature of Session, this design is in keeping with Session's design principles. The file server is fully open-source, with setup instructions provided so that users are able to set up their own file server. In an upcoming update users will be able to specify in the Session client which file server they want to use for attachment sending functionality. This is important both for providing users with choice and control, and ensuring the continued usefulness and functionality of Session if the OPTF were no longer able to maintain the default Session file server.
Session open groups servers (SOGS) are group chat servers that can host thousands of chat participants. This guide explains how to set up a Session open group server.
Note: Session open group servers provide transit encryption, but open group messages are not encrypted while stored on the server; closed groups (which can be created within Session itself) are a better solution for high-security communications with groups of 100 or less people.
Open groups are hosted using PySOGS. Written in Python, PySOGS is the reference implementation of a Session open group server. PySOGS is used to run the official Session open groups, and is the officially supported open group server.
Below you can find a video guide walking you through the process of setting up a Session open group server, as well as a written guide.
Note: .debs for the Session Open Group server are currently available for Ubuntu 20.04 and newer, and for Debian 10 and newer. For other operating systems, you can build from source
Typically, the simplest and cheapest way to host a server is by leasing a Virtual Private Server (VPS). There are hundreds of VPS providers to choose from, some popular options are: Vultr, Hetzner, DigitalOcean, Linode, Amazon Lightsail, etc.
You can run a SOGS from home, but consider most consumer internet connections have poor upstream bandwidth, typically don't provide a static IP address, and transient power and network outages are a relatively common. These factors can affect the stability of your SOGS and the ability for users to chat in your group.
Resource requirements are highly dependent on how many users you plan to support in your open groups and how frequent usage is, however, a good starting point would be:
1 Virtual core, 512 MB of RAM, 20GB HDD space
Once you have signed up for a provider you should receive a static IP address, you will need to SSH into your server, you can find instructions on how to do this online.
Add the Oxen apt repository by running the following commands
You have a choice to install either the sogs-standalone package or the sogs-proxied package.
This is the simple SOGS package for most setups. It installs a SOGS that listens on a public IP/port for HTTP connections. It does not support HTTPS connections (but since all messages to/from SOGS are separately encrypted, HTTPS is not necessary nor recommended).
This package provides a more advanced SOGS configuration where SOGS itself will listen on an internal port and expects to have requests proxied to it from an ngnix or apache2 front-end server that listens on the public IP/port. The package will install basic site configuration files for either nginx or apache2, but extra configuration may be necessary.
This package is required if you want your SOGS to be reached over HTTPS: the HTTPS handling is configured on the front-end server (i.e. in nginx or apache) using a tool such as certbot. (This package does not auto-configure such HTTPS certificates, but there are many online help pages on setting up such HTTPS support for a front-end web server).
If you don't know what any of this means then stick with the sogs-standalone package.
OR
If installing the standalone version you will see this prompt, asking you to enter a URL or IP address, if you have not setup DNS to point towards the IP address of your VPS then you should enter your VPS Public IP address, which can usually be found on your VPS provider's website.
Once finished with installation, you will want to add a room, to add a room run:
Replace TOKEN with the address to use in the room URL (which must consist of ONLY lowercase letters, numbers, underscores, or dashes), replace NAME with the room name to display in Session and optionally replace DESCRIPTION with a short description of the topic of the room.
As an example, setting up a room for discussion of Australian fisheries
Make yourself a global administrator for all rooms hosted on your SOGS by running the following:
Replace SESSIONID with the Account ID you want to be an administrator
For example:
Once setup, you should be able to navigate to your VPS's IP address in a web browser, for example http://116.203.70.33/
Here you should see a list of your rooms, clicking on a room will display a QR code and the link required to join the room, this link can be copied and pasted into a Session client to join a group.
SOGS is configured as a Debian package, it will be updated when you update and upgrade other packages on your system, you can trigger this process by running the following commands
If you're having trouble setting up your SOGS, we recommend opening an issue on the Session open group server GitHub repository. Contributors to the PySOGS software should be able to assist you in getting everything up and running.
Session is an open-source encrypted messenger powered by Oxen, designed to provide both security and anonymity through metadata minimisation, fully anonymous signup, and secure encryption and networking protocols. Session uses the Oxen Service Node network to route and temporarily store messages.
The past decade has seen a massive increase in the number of people using — and relying on — instant messengers for everything from chatting with friends to mission-critical business tasks. The most widely-used messengers have amassed more than a billion users. However, these popular messengers have some serious privacy and security shortfalls that make them completely unsuitable for anyone concerned about their online privacy.
Some messengers, such as WhatsApp, have deployed end-to-end encryption in an attempt to alleviate user concerns about privacy and security. However, simply encrypting the contents of user messages doesn't fix the wider underlying issue: the companies that operate these services can still see massive amounts of metadata about their users' messaging activities. This metadata can include user IP addresses and phone numbers, the time and #️quantity of sent messages, and the relationship each account has with other accounts. Increasingly, it is the existence and analysis of this metadata that poses a significant privacy risk to journalists, human rights activists, and other groups with a real need for private communications.
Session is, in large part, a response to this growing risk. Session is built to minimise metadata creation and leakage at every step of the messaging process. Through its fully anonymous signup process, decentralised networking infrastructure, and encryption and onion routing protocols, Session ensures that users send messages — not metadata.
You can download Session for Windows, macOS, Linux, iOS, or Android on the Session website, where you can also find more information about the app, including details about its encryption protocol and more.
Looking to register a permanent name for your Account ID? Head over to Using Oxen Name Service.
Session follows one of two distinct cases for message routing, depending on the availability of participating clients:
By default, or when either of the participating clients' statuses is determined as offline (see Synchronous Routing for how client status is determined), Session will use asynchronous routing. In asynchronous routing, the sender determines the recipient's swarm by obtaining the deterministic mapping between the recipient's long-term public key and the currently registered Oxen Service Nodes. This information is initially requested from a random service node by the sender and updated whenever the client gets an error message in the response that indicates a missing swarm.
Once this mapping is determined, the sender creates the message protobuf and packs the protobuf in an envelope with the information to be processed by service nodes: the long-term public key of the recipient, a timestamp, TTL ("time to live") and a nonce which proves the completion of the required proof of work. The sender then sends the envelope using an onion request to one or more random service nodes within the target swarm (in practice, each request is always sent to 3 service nodes to achieve a high degree of redundancy). These service nodes then propagate the message to the remaining nodes in the swarm, and each service node stores the message for the duration of its specified TTL.
Alice uses an onion request to communicate with three random service nodes in Bob’s swarm. Bob then uses an onion request to retrieve said message, by talking to three random service nodes in his swarm.
Session clients include their online status in the encrypted protobuf of any asynchronous message they send. Along with their online status, a sending client also lists an Oxen Service Node in their swarm to which they are listening via onion request.
When a Session client receives a message which signals the online status of another client, the receiver sends an onion request to the sender's specified listening node. The recipient also exposes their own listening node to the sender. If this process is successful, both sender and receiver will have knowledge of each others' online status and corresponding listening nodes. Messages may now be sent synchronously through onion requests to the conversing clients' respective listening nodes.
Alice uses an onion request to send a message to Bob’s listening node. Bob receives this message using an onion request, then sends a message to Alice’s listening node.
Messages sent using this synchronous method do not contain proof of work, and listening nodes do not replicate or store messages. To ensure messages are not lost, receiving clients send acknowledgements after receipt of each message. If either device goes offline, this acknowledgement will not be received, and the client which is still online will fall back to using the above asynchronous method of message transmission.
Friend requests are sent the first time a client initiates communication with a new contact. Friend requests contain a short message with a written introduction, the sender's prekey bundle, and meta-information like the sender's display name and public key, which the recipient can use to respond. Friend requests are encrypted for the public key of the recipient using ECDH. When a friend request is received, the client can choose whether to accept it. Upon acceptance, the client can use the prekey bundle to begin a session and start sending messages asynchronously.
