Psilocybin-Research.com Research. Clarity. Progress.

About this application

Psilocybin and psilocin literature, kept searchable and usable.

The Psilocybin Research Publication Tracker is a focused research application for finding, filtering, exporting, monitoring, and citing publications related to psilocybin and psilocin. It combines source-aware metadata ingestion, deduplication, publication-status labeling, analytics, alerting, exports, API access, PWA behavior, and public-safe operational monitoring for researchers, clinicians, journalists, policy analysts, and advanced readers who need fast access to scientific records without losing context.

What It Does

The tracker combines literature metadata from PubMed, Crossref, Europe PMC, OpenAlex, medRxiv, bioRxiv, PsyArXiv, and ClinicalTrials.gov. It keeps peer-reviewed papers, preprints, reviews, protocols, and clinical trial records visibly distinct while making the database searchable, exportable, embeddable, monitorable, and installable as a PWA. Records can be searched by keyword, author, journal, year, date range, source database, publication status, topic, study type, and substance.

  • Shows latest papers and matching results with DOI, PubMed, source, topic, and status links.
  • Separates published papers, preprints, reviews, protocols, and clinical trials.
  • Marks preprints clearly as not peer reviewed.
  • Provides analytics for topics, journals, authors, sources, publication trends, and date ranges.
  • Exports filtered records as BibTeX, RIS, CSV, JSON, and the full SQLite database.
  • Offers JSON API, embeddable widgets, RSS-compatible data routes, PWA install support, and offline fallback behavior.

Alerts And Monitoring

Users can subscribe to publication alerts for broad psilocybin or psilocin coverage, or target updates by keyword, author, journal, topic, substance, and cited DOI. Alerts use double opt-in: no digest is sent until the confirmation link is opened.

  • Alert preferences can be changed, paused, resumed, unsubscribed, or deleted from the manage page.
  • Daily update jobs import new records and can send email and Web Push notifications.
  • Duplicate prevention records reduce repeated alert delivery for the same publication.

Privacy

The public website is designed to be self-contained. It serves local JavaScript, CSS, fonts, images, manifest, and service-worker assets, with no CDN JavaScript, CSS, or web fonts required for the app interface.

  • Public API, export, widget, and RSS-compatible responses expose publication metadata, not private subscriber data.
  • Email alert templates contain no tracking pixel.
  • Alert data is used for requested publication updates and preference management.
  • Operational health output is public-safe and must not expose tokens, credentials, traces, or private runtime data.
  • A dedicated data protection notice documents user data, publication data sources, update jobs, third-party requests, and deletion options in detail.

Encryption

Sensitive alert and push-subscription fields are encrypted at rest in the application database. The app stores encrypted values plus blind indexes so it can find a subscription without keeping plain email addresses, access tokens, confirmation tokens, or push endpoints in lookup columns.

  • Alert email addresses, alert access tokens, and confirmation tokens are stored encrypted at rest.
  • Push endpoints, browser push keys, auth secrets, and user-agent strings are stored encrypted at rest where present.
  • Web Push payloads are encrypted for delivery using the browser subscription keys and VAPID signing.
  • HTTPS protects normal browser traffic in transit on the live site.

Non-Sensitive Security Stats

3,975Indexed records
8Source databases
SQLite + WALDatabase engine
OKStorage protection
OKBackup freshness
6Alert cipher/index fields
5Push cipher/index fields

These values are aggregate, public-safe indicators. They do not expose subscriber emails, push endpoints, tokens, private keys, filesystem paths, ciphertext, blind-index values, or raw health logs.

PHP Architecture

  • Plain PHP front controller: `index.php` renders the search-first app shell, filters, latest papers, analytics entry points, alert enrollment, admin-only curation, and SEO metadata.
  • SQLite repository layer: `src/Database.php` handles schema bootstrap/migrations, while `src/PublicationRepository.php` owns search, dedupe, analytics, classification, and curation queries.
  • Importer orchestration: `src/PublicationService.php` coordinates PubMed, Crossref, Europe PMC, OpenAlex, preprint-server, PsyArXiv, and ClinicalTrials.gov fetchers under `src/Fetchers/`.
  • AJAX search flow: search, pagination, and filter changes use asynchronous JavaScript requests, `fetch()`, `DOMParser`, and section replacement so result panels update without a full-page reload when JavaScript is available.
  • Progressive enhancement: all core search and export forms still work as normal PHP GET/POST routes without JavaScript; JavaScript adds smoother interaction, copy-to-clipboard, modals, timeline inspection, install prompts, and Web Push enrollment.
  • Defensive request handling: `RequestFilters::fromGlobals()` normalizes incoming filters, output is escaped through view helpers, admin operations are POST-only, and public refresh is bounded by lock/cooldown controls.
  • Dependency-light frontend: local SVG icons, native dialog sheets, native SVG charts, CSS media queries, and small focused JavaScript initializers replace heavyweight client frameworks for the public app surface.
  • Public endpoints: `api.php`, `export.php`, `database.php`, `widget.php`, `widget.js.php`, `status.php`, and `health.php` expose structured data and operational status without exposing private runtime secrets.
  • Notification services: `src/AlertService.php` and `src/PushService.php` handle double opt-in email alerts, preference management, Web Push subscriptions, encrypted payload delivery, and stale-subscription cleanup.
  • Runtime hardening: runtime data lives under `data/`, web access is denied by Apache rules, sensitive values are encrypted at rest, logs are JSONL with redaction, and SQLite backups are created through `bin/backup-sqlite.php`.

Data Provenance And Automated Updates

Every publication row keeps source and status context so records do not collapse into an undifferentiated feed. The app stores a `source_name`, normalized publication status, DOI, PubMed ID where available, source URL, raw importer metadata, timestamps, topics, substances, and study-type classifications so users can trace records back to source systems.

  • Source provenance: PubMed, Crossref, Europe PMC, OpenAlex, medRxiv, bioRxiv, PsyArXiv, and ClinicalTrials.gov records remain source-labeled in UI, API, exports, widgets, and analytics.
  • Status provenance: published papers, preprints, reviews, protocols, and clinical trials keep separate status labels; preprints remain visibly marked as not peer reviewed.
  • Deduplication logic: imported records are matched by DOI, PubMed ID, and normalized title to reduce duplicate papers while preserving source metadata.
  • Daily cron update: production runs `php bin/update.php --daily` from cron at 03:20 server time, which corresponds to 01:20 UTC during Central European Summer Time.
  • Operational traceability: fetch runs, fetch errors, heartbeat files, JSONL logs, update freshness, backup freshness, and public-safe health checks make update state auditable without exposing secrets.
  • Manual and targeted updates: admin-only commands support backfills, date-window refreshes, source-specific imports, reclassification, and targeted PubMed ID imports when curated repair is needed.

Data Compression And Speed

The app is built as a small, server-rendered PHP application with local assets and a compact SQLite data layer. The goal is to keep the first screen useful quickly while avoiding large frontend bundles, external CDNs, and unnecessary network round trips.

  • Compressed delivery: Apache is configured to use Deflate and Brotli modules when available, so HTML, CSS, JavaScript, JSON, manifest, and SVG responses can be transferred compressed.
  • Minified static assets: readable source files live in `assets/styles.css` and `assets/app.js`; production loads generated `assets/styles.min.css` and `assets/app.min.js` with versioned URLs.
  • Long-lived immutable caching: static images, fonts, CSS, JavaScript, icons, and manifest assets receive one-year immutable cache headers, while PHP/HTML responses use no-store semantics.
  • Local assets only: fonts, icons, imagery, service worker, manifest, and PWA icons are served from this domain, which removes CDN lookup latency and third-party frontend dependencies.
  • SQLite read performance: the database uses targeted indexes, source/status/topic/date filters, FTS5 where available, and WAL mode for better read behavior during update jobs.
  • Asynchronous interface updates: AJAX result loading updates only the changed result/filter sections instead of repainting the whole application shell.
  • Small runtime responses: API, export, widget, and health endpoints return focused JSON/HTML payloads; export/download routes are explicit rather than loading large datasets into the first viewport.
  • PWA caching strategy: the service worker caches the static app shell and uses network-first runtime requests so visitors get fresh publication data without re-downloading stable interface assets.
  • Operational checks: `health.php` monitors database reachability, update freshness, backups, storage permissions, logs, and heartbeat files so performance and reliability problems are visible early.

Scientific Context And Limits

The database is a discovery and monitoring tool, not a clinical guideline and not a substitute for source verification. Bibliographic coverage can be incomplete, source metadata can contain errors, and deterministic topic classification is only a navigation aid. Users should verify records at the publisher, registry, PubMed, DOI, or source database before citation, reporting, clinical interpretation, or policy use.