Privacy Policy

This is a convenience translation. In case of doubt, the German version (Datenschutzerklärung) prevails.

This policy explains which data this messenger processes. The Swiss Data Protection Act (FADP) applies and – insofar as users from the EU use the service – the European General Data Protection Regulation (GDPR).

1. Controller

Fabian Meyer, Weissensteinweg 10, 5330 Bad Zurzach, Switzerland
E-mail: fabian@diemeyerz.de

2. What data is processed

Account data: a self-chosen username, a password and optionally a profile picture. The password is stored exclusively as a cryptographic hash – the operator never knows the plain-text password. The profile picture is visible to other users and can be replaced at any time.
Two-factor sign-in (optional): if you enable it, a secret key is stored from which your authenticator app generates the six-digit codes, along with eight backup codes in case a device is lost. The backup codes are stored exclusively as a cryptographic hash and can each be used once. You can switch the feature off at any time; the data is deleted when you do.
Content: messages as well as sent images, videos and voice messages. They are stored on the server so that they can be delivered to recipients and conversation histories can be displayed.
Contact and group data: who has added whom as a contact and who is a member of which group. Group and server names, group descriptions and nicknames you give your contacts are stored unencrypted – see section 4.
Classified ads (marketplace): posting an ad deliberately publishes its title, description, price, category, images, location and postcode. This information is visible to other users and therefore not end-to-end encrypted – it could not be searched otherwise. Every ad page states this. The chat about an ad is encrypted like any other chat. Ads expire after 60 days and are deleted together with their images 30 days later.
Location (voluntary): your location may be used for the radius search. It is not stored, only used for the duration of that request. Coordinates are stored with an ad only if a location was given, and are deliberately rounded to two decimal places (roughly one kilometre), so no street address can be derived from them.
Camera and microphone: accessed only when you deliberately start a recording (photo, video, voice message, call, status post) and only with the browser's permission. Nothing is recorded in the background. Images and videos are downscaled and encrypted on your own device before upload; edits such as filters, text or cropping also happen entirely on the device.
Technical data: IP addresses inevitably appear in the web server's logs. A session marker is stored persistently in the browser (localStorage) so you do not have to sign in on every start; it is removed when you sign out. Your chosen language and appearance setting also stay in the browser. To prevent bulk account creation, the number of new accounts per IP address and day is limited; the server keeps those timestamps in memory only, never in the database.
Account settings: the status you choose (online, away, busy, invisible), which chats and servers are pinned to the top, which are muted and until when, how much a channel should notify you, and the expiry period set for a chat. These are stored unencrypted because the server has to act on them – it can only hold back a notification if it knows that it should.
Archived chats: which chats you have moved to the archive is stored – otherwise the server could not present them differently. This concerns the filing only, not the content; encrypted stays encrypted.
Starred messages: when you star a message, the server stores only its number – not its content. The collection becomes readable again only on your device. The operator therefore does not learn what someone considers important, only that something was marked.
Polls: question, answer options and the votes cast are ordinary end-to-end encrypted messages. The server can neither read nor count a poll; the result is produced on the participants' devices.
Link previews: see section 4e – the server retrieves a third-party page for this.
Marketplace: How often an ad has been viewed and saved is kept as a plain counter on the ad and shown only to the person who posted it – who viewed it is not stored. So that repeated visits do not distort the number, the server remembers for six hours, in memory only, who last opened which ad; this never goes into the database. Which ads you have looked at ("Recent") is stored on your own device only.
Saved searches (optional): Saving a search so that new matches are reported stores search terms, category, place and price range in plain text on the server – otherwise it could not check new ads against them. This applies only to searches you explicitly save; ordinary searching is not recorded. Every saved search can be muted or deleted at any time.
Ratings (optional): After a deal about an ad you can rate the other party. Rating and text are publicly visible and unencrypted – that is their purpose. Only someone who actually had contact about that ad can rate, and only once per ad. A rating can be deleted only by whoever wrote it; anyone who considers a rating unfair can report it.
Push notifications (optional): if you enable notifications, your device obtains a delivery address from the push service of your browser vendor (e.g. Google, Apple or Mozilla); this address is stored on the server and delivery technically runs through that service. Notifications never contain message content – only the fact that a new message exists and the sender or group name. You can revoke this at any time in your browser settings.
If Wirio is used as a mobile app, the same path does not run through the browser but through Google’s Firebase Cloud Messaging – an app shell has no push service of its own. The device obtains a delivery token there; that token and a short device description (the system or browser identifier, truncated to 120 characters) are stored on the server so that several devices can be told apart. Here too: never any message content.

Stays on your device: messages you have started but not sent (drafts) and the volume at which you hear individual people in a voice channel. Both are stored in the browser only and are never transmitted to the server.

Not used: advertising, tracking services, analytics tools, third-party cookies, or any sharing of data for commercial purposes.

3. Purposes and legal bases

Processing takes place solely to provide the messenger service (delivery and display of messages; Art. 6(1)(b) GDPR) and to ensure the security and stability of the service (Art. 6(1)(f) GDPR).

4. End-to-end encryption

All data is transmitted encrypted (HTTPS/TLS). In addition, all message content is end-to-end encrypted: text messages in one-to-one and group chats as well as all sent media (images, videos, voice messages). Content is encrypted on the sender's device and only decrypted on the recipients' devices. On the server it exists exclusively in encrypted form that the operator cannot read; for media files the server cannot even tell what kind of content they contain. Private keys never leave the users' devices.

Transparency about the limits: data the server needs for delivery and operation is not encrypted. This is the honest state:

Metadata: who writes with whom and when, contact lists, group memberships, read receipts and timestamps.
Usernames, chosen display names and profile pictures – they have to be visible to others.
Names of groups and servers, group descriptions and group pictures. The server needs them, among other things, to show which chat a notification came from.
Nicknames you give your contacts yourself.
Reactions to messages and status posts (the emoji itself) and who viewed a status post.
All details of a classified ad (see section 2).
Messages sent before encryption was introduced remain unencrypted.

Status posts are end-to-end encrypted as well – images and videos as much as any accompanying text, the chosen filter and the image placement. Only your own contacts receive a sealed key copy. The server does store the file name of the attached file in the clear; it needs it to reliably delete the file once the post expires, and the name reveals nothing about the content. Status posts are automatically and completely deleted after 24 hours, including image and video files. It is also stored which contacts viewed a post and which emoji they reacted with.

Note: since private keys exist only on the respective device, end-to-end encrypted messages cannot be recovered after switching devices or clearing browser data.

4a. Voice and video calls

Calls are transmitted directly between the participants' devices (peer-to-peer, WebRTC) and are always end-to-end encrypted (DTLS-SRTP). Audio and video never pass through the server; it only brokers the connection setup. For technical reasons the participants' devices exchange their IP addresses with each other. A STUN service (currently operated by Google) is used for connection setup and thereby learns the device's IP address – it does not receive any call content. Calls are not recorded or logged on the server.

4a-bis. Reporting and blocking

Reporting something deliberately sends the content of the reported item in the clear to the operator – that is, unencrypted. Without this a report could not be examined at all, since the operator otherwise cannot read encrypted content. Only the single reported message or post is transmitted, not the rest of the conversation. The reporting dialog states this explicitly before anything is sent.

Stored are: the reported content, the stated reason, an optional note, who reported, who was reported and the time. This serves solely to examine the case (Art. 6(1)(f) GDPR – legitimate interest in protecting users and in lawful operation) and is deleted once handled, at the latest after twelve months.

Blocking severs the connection to that person: existing contact links and pending requests are removed, messages and calls no longer arrive, and current status posts become inaccessible to them. A block can be lifted again at any time.

4b. Servers and channels

A group can be turned into a server with several text channels. Each channel technically is a group of its own, so messages in it are end-to-end encrypted exactly like in any other chat. The names of the server and its channels are stored unencrypted so they can be shown in overviews and notifications.

4c. Postcode and place directory

The place search in the marketplace uses a directory of European postcodes and place names held on our own server. The search therefore never leaves the server; no third-party map service is embedded and no request goes outside. The data is based on the GeoNames directory, used under the CC BY 4.0 licence.

4d. Voice channels and screen sharing

In a voice channel the audio is transmitted directly between the devices – as in a call – and is end-to-end encrypted (DTLS-SRTP). With several participants, every device connects to every other one; the server only brokers the connection setup and receives no conversation content. The same applies to screen sharing: it also runs directly between the devices, is not routed through the server and is not recorded. For technical reasons the devices involved exchange their IP addresses with each other.

So that it can be shown who is currently in which channel, the server stores this assignment – user and channel number plus whether someone is muted or deafened. It is held in memory and additionally saved to a file so that a restart of the service does not throw anyone out of a conversation. The file is read back on the next start and discarded if it is older than five minutes; it contains no conversation content.

4e. Link previews

If a message contains a link, a preview card with title, short description and image can be shown. This card is fetched by the sender's device before the message goes out and then travels inside the encrypted message. The receiving side loads nothing from the linked site – so that site does not learn that or when a link was read.

Because a browser is not allowed to fetch third-party pages itself for security reasons, the server does this on behalf of the sender. Two consequences follow, which are stated explicitly here: the operator learns which address someone sends (not the message text and not who reads it), and the page requested sees the server's IP address, not the device's. The retrieved information is not stored permanently. Only publicly reachable addresses over http or https are requested.

4e-bis. Contact suggestions

The contact list suggests people who are connected to your own contacts. This is meant to make the start easier: a new account otherwise faces an empty list.

What this reveals, plainly: that someone is suggested means they are connected to at least one of your contacts. That information is the suggestion – it cannot be avoided without dropping the feature.

What is not revealed: names of shared contacts are never shown, only their number („2 contacts in common“). Who is connected through whom never leaves the server.

Not suggested are: existing contacts, people with a pending request in either direction, and anyone involved in a block – in either direction.

Can be switched off: under Settings → Security you can turn off „Be suggested to others“. After that you no longer appear as a suggestion to anyone. The default is on; the legal basis is the legitimate interest in a usable service (Art. 6(1)(f) GDPR), which you can object to here.

4f. Wirio as an app on your device

Besides the browser, Wirio can be used as a mobile app and as a program for Windows, Mac and Linux. Both are shells around the same page: they load the actual application from the server and collect no data of their own. Nothing is added that would not also arise in the browser – with these differences:

The desktop program remembers on your own device how large the window was and where it stood. This never leaves the device.
It checks regularly whether a newer version exists and fetches it if so. It asks only our own server – no third-party service is involved. This produces the same as any other page request: the IP address in the server log.
Notifications in the mobile app run through Firebase, see section 2.

4g. Signing in another device

A second device can be signed in by having the already signed-in device read a QR code. The procedure is built so that the operator learns nothing beyond what they already know:

The new device deposits a throwaway key and receives a 32-character random number, which is what the QR code contains.
The signed-in device shows what kind of device is asking – roughly as “Windows”, “Mac”, “Android”, “iPhone/iPad” or “Linux”, so that you can tell whether it is you – and you confirm by hand.
It then seals the private key for the new device’s throwaway key. The server cannot read it; it only passes it on and creates the session.
This data exists in memory only, never in the database, and expires after two minutes. A photographed QR code is worthless after that.

4h. Usage figures

The operator can call up an overview of how the service is used. It contains sums only: how many accounts exist, how many were added in recent days, how many messages have been sent in total, how many groups, channels and listings there are.

What it does not contain: no name, no identifier, no list of people and nothing from messages – their content is not accessible to the operator anyway. Figures such as “active accounts” are plain counts; who is included is not output. No location is collected.

The purpose is operating and developing the service (Art. 6(1)(f) GDPR – legitimate interest). The overview is limited to the operators’ accounts.

5. Hosting

The service runs on a server managed by the operator and rented from the following provider:

netcup GmbH, Daimlerstraße 25, 76185 Karlsruhe, Germany

The server is located in a data centre in Germany; all data is processed and stored there. netcup acts as a processor within the meaning of Art. 28 GDPR on the basis of a data processing agreement. As the data centre operator, the provider technically has access to the infrastructure – however, message content and media are stored there exclusively end-to-end encrypted (see section 3) and therefore cannot be read by the hosting provider either. Beyond that, data is not passed on to third parties unless there is a legal obligation to do so.

6. Storage period

Account, contact and content data remain stored as long as the account exists.
On request an account including all associated data will be deleted – an informal e-mail to the address above is sufficient.
Status posts are deleted automatically 24 hours after publishing – entry and file alike.
Classified ads expire after 60 days and are deleted together with their images 30 days later.
An expiry period can be set for a chat (24 hours, 7 days or 90 days). Messages written after that carry an expiry date and are permanently deleted by the server at regular intervals. The setting applies to the chat, not to an individual person, and everyone involved is informed about a change. It only affects future messages. Explicit note: only the copies on the server and in the app can be deleted – anything recipients copy, photograph or save beforehand cannot be recalled this way.
The assignment of who is in which voice channel is deleted on leaving; the corresponding backup file expires after five minutes.
Pinned chats, starred messages and notification settings exist as long as the account exists and are deleted together with it.
Server logs are kept only briefly for troubleshooting and abuse prevention.

7. Your rights

You have the right to information about the data stored about you, to rectification, erasure, restriction of processing, data portability and objection to processing. Please contact the e-mail address above. You also have the right to lodge a complaint with a data protection authority – in Switzerland the Federal Data Protection and Information Commissioner (FDPIC), in the EU the competent national authority.

8. Changes

This policy will be updated whenever the functionality of the service changes.

Last updated: 28 July 2026 (4th revision)