Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prefer sharing permanent URLs when user has own domain-based identity #6250

Open
nileshtrivedi opened this issue Nov 12, 2024 · 2 comments
Open
Labels
feature-request A request for a new feature

Comments

@nileshtrivedi
Copy link

nileshtrivedi commented Nov 12, 2024

Describe the Feature

Let's say I am trying to share a Bsky post elsewhere on the web. I use "..." menu and choose the "Copy link to post" option on webapp or "Share" option on mobile app. The URL for the post shared is something like: https://bsky.app/profile/nilesh.trivedi.link/post/3laqk2h2rc22h even though this user is using a domain-based identity "nilesh.trivedi.link".

This has profound implications. The more such links are shared, the more locked-in users get into bsky app host, at least for accessing their past content, despite bringing their own domain for identity. The whole point of domain ownership is to have durable links to content. at:// links have this property but it is possible to get both durability and web-compatibility with the help of CNAME records.

Bluesky should encourage users' ownership for their content as much as possible, and not try to insert itself as a permanent intermediary between users' posts and their audience.

We need an option, preferably the default, to share post URLs which are both user-owned AND web-compatible. This does not require a change in the protocol, only in the application. The user already added a custom TXT record to prove their domain ownership for the the purpose of handle/username. They can be asked to add a CNAME record like at, pointing to the app's server.

So, instead of https://bsky.app/profile/nilesh.trivedi.link/post/3laqk2h2rc22h, I would like the default shared URL to be https://at.nilesh.trivedi.link/post/3laqk2h2rc22h which is shorter, gives ownership to the user and works in the existing web browsers.

This would be similar to Github Pages supporting custom domains via CNAME records.

Ideally, the content would be served directly on https://at.nilesh.trivedi.link/post/3laqk2h2rc22h but if there are security concerns, an HTTP redirect to https://bsky.app/profile/nilesh.trivedi.link/post/3laqk2h2rc22h would also be fine.

Since Bluesky is growing and links are already being shared on the web, this should be implemented as soon as possible to ensure durability and user-ownership of links.

Attachments

No response

Describe Alternatives

No response

Additional Context

This came up in this BlueSky thread.

@nileshtrivedi nileshtrivedi added the feature-request A request for a new feature label Nov 12, 2024
@vyv03354
Copy link

This would be similar to Github Pages supporting custom domains via CNAME records.

Ideally, the content would be served directly on https:/at.nilesh.trivedi.link/post/3laqk2h2rc22h but if there are security concerns, an HTTP redirect to https://bsky.app/profile/nilesh.trivedi.link/post/3laqk2h2rc22h would also be fine.

This is already possible. Set redirect.bsky.app. on your CNAME record. See https://bsky.app/profile/jacob.gold/post/3kh6re46yd42k for details.
Example URL: https://bsky.emk.name/post/3l745ub3npc2n

@nileshtrivedi
Copy link
Author

@vyv03354 That is great! Also "bsky" and "bluesky" are considered special as they are stripped before redirecting to user's profile. So, with an ALIAS record set up, now https://bsky.nilesh.trivedi.link/post/3laqk2h2rc22h indeed redirects to https://bsky.app/profile/nilesh.trivedi.link/post/3laqk2h2rc22h 👏

Would love to know if this feature is still experimental. Once this gets tested well, Bluesky should make these as the default URLs when sharing posts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request A request for a new feature
Projects
None yet
Development

No branches or pull requests

2 participants