Notifications from the Bluesky service will use display name, e.g. "Grace" instead of "@gracekind.net". Similar to #1, this is a minor item for parity between services.
Something went wrong. Try again.
Something went wrong. Try again.
Notifications use handle, not display name #3
Follow-up: tang's issue comment subcommand was writing to sh.tangled.repo.issue.comment, which the web UI never renders; the issue page reads sh.tangled.feed.comment (subject is a strongRef to the issue, body a markdown union). Patched my fork (7778777.online/tangled-cli, branch fix-comment-collection) so comments land where the web reads them.
I think it actually works now, although I haven't checked with the re-grant to get this privately, so on an old-style grant the display name lookup leaks on chat participant lookup
Audit follow-up: app notifications were already able to use author.displayName, but the chat part of my original fix was not done. It called app.bsky.actor.getProfile through a grant that never requested that scope, so chat names fell back to handles.
That was corrected separately in c329c9b: new grants can request the optional profile scope; older grants use a public profile lookup, and the subscriber own messages are never looked up. Your later confirmation matches the deployed behavior. The current implementation and its grant/public-fallback, self-skip and encrypted-push tests are in main.
The phone also showed the expected display name in the like-banner verification for #1. No further code change was needed for this issue in 59c0445.
Fixed on the fix/display-names branch. App notifications carry the display name in the listing already (author.displayName), so banners, burst summaries and grouped targets all read it from the item; chat previews look the sender's profile up once per account (the log carries only a DID) and cache it for an hour. A push names a person as Grace (@gracekind.net) - display name first, handle parenthesized - so two people sharing a display name stay distinguishable on a lock screen; an account with no display name set falls back to the bare handle. Deeplinks still use the handle, since a display name is not an address. Deployed live on courier.7778777.online - the first live row carrying a display name is already in the database (Top Chicken Market for topchicken.cee.wtf).