idno/known

A social publishing platform.

Fund package maintenance!
Opencollective

Installs: 271

Dependents: 0

Suggesters: 0

Security: 5

Stars: 1 107

Watchers: 64

Forks: 198

Open Issues: 139

Type:project

pkg:composer/idno/known

1.6.3 2026-02-13 20:13 UTC

README

Build Status

Idno: a social group platform

Idno - A social group platform

Installation

One-click Idno sites

If you want to install on your own web space, we recommend Reclaim Hosting, which includes one-click Idno installation. Idno is also known to work on DreamHost, a high-quality web hosting provider.

Installing

Idno is under active development and requires PHP 8.1+ with selected extensions, together with a supported database backend. You can find detailed installation instructions here: http://docs.idno.co/en/latest/install/index.html

Installing from packages

Unofficial install packages, which are periodically built from the latest code, are available: https://www.marcus-povey.co.uk/known/

Installing from Github

You can opt to check out the work-in-progress development code from the git repository: https://github.com/idno/idno

  • Check out the repo: git clone https://github.com/idno/idno.git
  • Fetch dependencies: cd idno; composer install

Installing with composer

You can install Idno directly from composer using: composer create-project idno/idno

Optionally, you can install the latest bleeding edge code the same way: composer create-project idno/idno -s dev

Setting up the async pipeline

By default, Idno processes events synchronously — that is, things like Webmention pings, syndication, and ActivityPub delivery all happen inside the web request that triggered them. This works, but it makes page saves slow and means a timeout or crash loses the work.

Enabling the asynchronous queue moves all of that into a background worker. The web request just drops an event into the database and returns immediately; the worker picks it up and processes it separately.

This is required for ActivityPub. Follow-accept delivery, post distribution to followers, and update/delete propagation are all dispatched through the queue. If the worker is not running, those events sit in the database unprocessed and remote servers will never receive them.

1. Enable the async queue

Add this line to your config.ini:

event_queue = 'AsynchronousQueue'

Without this line (or with the default SynchronousQueue), all events are processed inline during the web request.

2. Start the event queue worker

sudo -u www-data KNOWN_DOMAIN='your.domain' ./idno.php service-event-queue
Option Default Description
--queue default Named queue to process
--interval 1 Seconds to sleep between polling cycles

How it works: The worker runs an infinite loop. Each cycle it:

  1. Queries the database for up to 50 pending events.
  2. Dispatches each one via an internal HTTP call to /service/queue/dispatch/{id}, which triggers the event handler (e.g., signing and POSTing an ActivityPub activity to a remote inbox).
  3. Runs garbage collection to remove completed events older than 5 minutes.
  4. Sleeps for --interval seconds, then repeats.

If the worker dies, queued events pile up in the database but are not lost. They will be processed once the worker is restarted.

3. Keep it alive with systemd (recommended)

The worker must stay running permanently. The simplest way is a systemd service unit. Create /etc/systemd/system/idno-queue.service, taking care to replace the values here with your own paths, users, and domains:

[Unit]
Description=Idno async event queue worker
After=network.target

[Service]
Type=simple
User=www-data
Environment=KNOWN_DOMAIN=your.domain
WorkingDirectory=/var/www/idno
ExecStart=/var/www/idno/idno.php service-event-queue #replace with your path
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Then enable and start it:

sudo systemctl daemon-reload
sudo systemctl enable --now idno-queue

Check status any time with:

sudo systemctl status idno-queue
sudo journalctl -u idno-queue -f   # tail the logs

4. Run the periodic cron service (optional)

If you need periodic background tasks (triggered via cron/minute, cron/hourly, and cron/daily events), start the cron service the same way:

sudo -u www-data KNOWN_DOMAIN='your.domain' ./idno.php service-cron

You can create a second systemd unit (idno-cron.service) following the same pattern as above if you want it managed automatically.

5. After updates — restart the workers

When you update Idno core or any plugins, restart both services so they pick up the new code:

sudo systemctl restart idno-queue idno-cron

Support us

Get support

Community links

For details on contributing to the Idno project, please read CONTRIBUTING.md.

Contributors

This project exists thanks to all the people who contribute. [Contribute].

See contributors on GitHub.

Copyright and License

Except for included third-party projects, Idno is (c) The Open Community Company LLC.

Unless otherwise stated, Idno is licensed under the Apache Software License 2.0. See LICENSE for more information.

Idno logos are (c) Idno, Inc. Permission from Idno, Inc is required to use the Idno name or logo as part of any project, product, service, domain or company name, except as included in official themes distributed by Idno.

Logos of external services are (c) their respective owners. All rights reserved.

Third party libraries are licensed separately.

Idno also contains

Thank you

BrowserStack Logo

Thanks to BrowserStack for providing the infrastructure that allows us to test in real browsers.