Oddbean new post about login | logout I see some privacy issues here. Someone might start giving more value on their privacy and change the picture to something more low-profile. Respecting the user's decision is a better choice in this case imo.
Once it’s out there, it’s out there. I respect people’s option to change their profile pics. But it’s my eyeball seeing the image. Who ought to have say over what I choose to have my own screen show me?
If you're a responsible relay operator invested in the ethos of this space...that first sentence really hits hard. If one of my users wants or needs to change their pic URL in this space, I don't wanna be one of the assholes that gets in their way.
I fully support people freely choosing to change their profile pics as often as they like. I fully support relay operators freely choosing to honor or ignore updates to profile pics at their own discretion. What I’m asking for is the same freedom to choose at the client (recipient) level. Clients already have tooling to allow users to conditionally ignore some kinds of incoming information: mute conversation, mute user, mute keyword, etc. All I’m asking for is to conditionally ignore another kind of broadcast, the profile pic update.
There's no such thing as a profile pic update. There's just a kind 0 event, so if you block updates, you block any change to the profile. You would have to locally cache the pic and then never clear the cache (which is a bug, not a feature, sorry), list the NIP-05 next to the handle in the notes (easiest fix), or use NIP-81 (which is work to implement, but has the most long-term potential).
Nip-81 is the winner but clients just don’t want to do the work.
NIP-81 seems fine. It puts the client configuration on the relay but satisfies the same requirement.
It allows your configuration to travel with you when your client rugs you.
Easiest (and most fun!) fix is nicknames
> You would have to locally cache the pic and then never clear the cache I’m thinking something like this: 1. Receive and store (cache) all profile update events. 2. Allow user to “pin” a particular pic image, but continue to receive and store updated profile events. That is, in client-side storage, map the npub to the note id with the pinned profile pic. 3. When a follow’s profile updates, show “<name> has a new profile pic” as a notification like any other. The notification UI can have a pin/unpin button or something to allow the user to decide whether to accept the new pic as the pinned one. 4. When viewing an npub’s profile, show the gallery of previous profile pics. Allow client to pic one to pin. Or “unpin” to always use the latest profile pic. Notably, Telegram shows users’ prior profile pics. I don’t think it gives users the ability to pin other users’ pics (for their own viewing), but it does preserve the history of pics you can look through.
Okay, that doesn't sound at all creepy. 😅 https://media.tenor.com/o_RMXS4j2gYAAAAC/kto-kounotoritoken.gif At any rate, anything in-app is siloed data and will trap people into a client, but it allows you to write all sorts of nasty stuff you don't want anyone else knowing about, so I see the upside. If you're doing it client-side, why bother even using the pics from the profiles? You could change my profile pic to anything.
> why bother even using the pics from the profiles? You could change my profile pic to anything. If you’ll pardon the philosophical diversion, the value of a profile pic at all, IMO, is recognizability at a glance. There are plenty of ways to share one-off content images. The point of a profile pic, specifically, is so the viewer can identify the content creator quickly. To this end, using the pic that the creator has chosen makes sense in nearly all cases. The creator has indicated “this is how you can quickly identify me”. When a profile pic changes, especially frequently, it breaks the very point of having one. It’s a new, unrecognized image in a scenario where recognizability is the primary function. I accept that the above is my opinion. I accept that others have their own opinions about the purpose and value of profile pics. What I’m looking for is a solution that preserves the utility of profile-pic-as-recognizable-avatar in the face of these differences of opinion.
There. Fixed the problem.
I wonder what would happen if someone used Lorem Picsum https://picsum.photos/200
If you're a client developer...that last sentence hits hard. A user changed their profile pic URL to a broken link. Do I continue to show the old one, just because I remember it, and the user is familiar with it?
