Seldeo

Legal

Safety Community Guidelines Privacy Policy Terms of Service Cookies DMCA Transparency
More

← All news

Share links: how a Seldeo URL travels the open internet

2026-08-03By Shoeb Khan

The problem share links solve

The most common way a Seldeo user reaches a friend outside Seldeo is a shared URL — a link to a post, a memorial page, a profile, a story slide, or an image. That URL has three jobs to do, in tension with each other:

  1. Open the Seldeo app on the recipient's phone if it's installed.
  2. Open a graceful web page if it isn't installed, and give the recipient a way to install the app if they want to.
  3. Not leak any more information about who's sharing what to whom than the recipient's browser inevitably discloses.

This post explains how Seldeo's share-link system does those three things.

The URL shape

Every share URL on Seldeo has the form:

https://www.seldeo.com/p/<slug>

The <slug> is a short, opaque identifier. It carries no personal information. Two share links can point to the same underlying content — the poster can generate a new share link and the old one continues to work.

The /p/* prefix is deliberately generic: a link to a post, a story, or a memorial page all look the same in the URL bar. No public signal in the URL structure discloses what kind of object is being shared.

What the browser sees

When the recipient taps the link in a chat, an SMS, or a browser, the browser fetches the URL as it would any web page. Two things happen next:

  • If the recipient is on iOS or Android and has the Seldeo app installed, the OS's Universal Links (iOS) or App Links (Android) system routes the URL to the app before the browser opens it. The app handles the URL directly and no web page is loaded.
  • If the app is not installed, the browser loads the share page — a lightweight, no-tracking page that shows a preview of the content, a "Get Seldeo" button, and an "Open in browser" fallback for public content.

The magic that makes this work is the two .well-known/ manifests, apple-app-site-association and assetlinks.json. These declare to iOS and Android that seldeo.com's /p/* paths belong to the Seldeo app. Publishing them correctly is the difference between a smooth deep-link and a browser detour.

The share page

The share page is the fallback rendered when the app isn't installed. It:

  • Shows a preview of the underlying content — for a post, the first image plus the caption; for a memorial page, the person's name and photo; for a public profile, the display name and bio.
  • Uses only self-hosted CSS. No third-party fonts (system fonts only), no third-party JavaScript, no third-party images (the preview asset is served from Seldeo's own storage).
  • Loads no analytics or advertising SDKs. Not GA. Not Meta Pixel. Not TikTok Pixel. Not anything.
  • Sets robots-fragment.txt on the /p/ prefix so the share URL is not indexed by search engines. This is deliberate: a share URL is for the person the poster chose to share with, not for Google.
  • Serves clear OpenGraph and Twitter Card metadata so the chat client the URL was pasted into can render a rich preview.
  • Does not read or write any cookies to the recipient's browser.

The one call the share page makes to Seldeo's backend is a signed request for the preview payload for the specific slug. That request carries only the slug and the recipient's IP address (which is unavoidable at the network layer). It does not carry any identifier for the recipient.

What the poster sees

The poster does not see who tapped their share link. There is no "seen by" indicator on public share URLs. Share-link metrics available to a poster are limited to:

  • Total taps on the link, since it was created.
  • Rough geographic distribution (country level), where enough taps have accumulated that individual users can't be identified.
  • Nothing more.

We know that share-link analytics are a common feature on other platforms. We have deliberately declined to build the richer version. The person who tapped the link owes the poster nothing but the tap itself.

What we don't do with a share URL

  • We don't append tracking parameters (utm_source, utm_medium, session cookies, click IDs) to a share URL. A share URL is what the poster tapped Copy on and nothing more.
  • We don't shorten share URLs through an intermediate redirector. The link the poster copies goes directly to seldeo.com. No sldo.co domain, no click-tracking layer.
  • We don't publish share URLs on any Seldeo-owned page. Public profiles link to public content by its permalink, not by a share slug.
  • We don't reserve a share URL forever. If a share URL is associated with content that gets deleted or has its audience narrowed, the URL becomes a 404 (or a "This content is no longer available") page.

The security boundary

There is exactly one Cloud Function that resolves a share slug to preview metadata: seldeo-share. It has strict scopes:

  • Read-only access to the subset of data records that contain shareable content.
  • No write access.
  • No auth-token minting.
  • No access to any user's private data.

If you're a security researcher and you want to look at the share-link resolution path, the code lives in the seldeo_share_cloud_functions repository. The /.well-known/security.txt file on seldeo.com is the right route for coordinated disclosure of anything you find.

What's next

  • Signed share URLs for private content. So a user who wants to share a friends-only post with a specific person can, without making the post public first.
  • Time-limited share URLs. For story shares, so a shared URL expires with the story itself.
  • A share-link privacy dashboard. So a poster can see the small number of metrics we do surface, and can invalidate a shared URL if the situation changes.

Share links are a small feature that carries a lot of privacy weight. The design principle is the same one that runs through the rest of Seldeo: collect the minimum, publish nothing you don't need to, and never let a recipient's tap become a data point that follows them.