This #meme hits hard nostr:note14xn2zzhu3cc22mq9d0c8qxw8mxs8utedzc259u873gxyun7gp92s9tgvhx
What are Pleroma and Ditto?
A manās phone is his castle.
I wonder what would happen if someone used Lorem Picsum https://picsum.photos/200
Thatās a good point. The ability to change clients easily is one of Nostrās great strengths. Itās important to not sacrifice this feature in the interest of achieving something else.
> 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.
In the semantic web, IIRC, ārelationshipā is indeed a term of art for data about a pair of entitiesālike an edge in a graph.
But yeah ārelationship statusā has a certain other connotation in English. š
Hashes of content are an acceptable compromise. So you still have a URL, but the client can at least assert that the content matches the expected hash.
> 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 ā
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.
NIP-81 seems fine. It puts the client configuration on the relay but satisfies the same requirement.
What Iād like to see, and Iām probably the only one, is support for data:// URIs, paired with SVG support.
An SVG image can be quite small and yet vibrant. It would be possible to URL-encode or base64 encode a small SVG file and cram it directly into a Nostr note by way of a data:// URI.
Or even gzip+base64 SVG in a data:// URI.
Thatās a great point. Trust is willingness to be vulnerable. I wouldnāt say I ātrustā people I follow just because I like their content. š
Sorry about that. I think my original message came off harsher than I meant it. You make good content, and your profile pic updates are only a minor annoyance to me.
Itās not that I donāt recognize you when you change it. Same face, obviously. What I think gets to me is that it commands my attention. Like an advertisement in the middle of a video. Something I have to look at and assess. It takes me out of the flow of what I was doing.
I block video ads by paying to upgrade on every platform that supports it. I avoid watching media with ads that I canāt pay to opt out of. Iām looking for the same opt-out here.
Aside: Someone brought up a good point which is that the profile pics are themselves out-of-band. Theyāre just links. Itās the HTTP server that actually determines the displayed bytes, and that server can optionally serve different content arbitrarily.
So even an option to ignore updates wouldnāt necessarily freeze the profile pic on the recipient side. It takes cacheing at the byte level as well.
Really I should stop complaining and just write my own client.
Thatās another great argument for client-side profile pic cacheing.
The HTTP server serving the profile pic may change the underlying image that it serves with no change to the actual profile.
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.
I for one support your choice to change your profile characteristics at will, as often as you like. You control the rate at which your published info changes.
Iām asking for a client to give me the equivalent, consumer-side freedomāto control the rate at which consumed info changes.
Itās not hard, IMO. Give both people options. Let people change their declared profile pics. Let recipients decided which historically declared profile pic to view. There doesnāt have to be exactly one solution for everyone.

