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-03 By Sarah Lee

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.
  • Loads its presentation and preview media from Seldeo. It does not depend on third-party fonts, scripts, or images.
  • Loads no analytics, advertising, or behavioral-tracking services.
  • Asks search engines not to index share URLs. This is deliberate: a share URL is for the person the poster chose to share with, not for search results.
  • Provides rich-preview information so the chat or messaging app receiving the URL can show useful context.
  • Does not read or write any cookies to the recipient's browser.

The share page retrieves only the preview associated with the specific slug. The request carries the slug and the recipient's IP address, which is unavoidable when connecting to a website. It does not carry an account or device 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.

Privacy and security protections

Share previews are resolved through a narrowly scoped, read-only capability:

  • It can retrieve only information approved for a share preview.
  • It cannot change content or account data.
  • It cannot create sign-in credentials.
  • It cannot access private user data.

Security researchers can report concerns about the share-link resolution path through /.well-known/security.txt, our canonical route for coordinated disclosure.

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.