Description:
Assuming the journal owner has allowed it, a commenter would be able to select "Do not identify me publicly" (or some much smoother phrase) as an option when commenting, so that their comment is displayed as anonymous to everyone but the journal owner (or the community's admins).

This would allow many of the benefits of an anonymous discussion taking place in the public sphere (people who cannot for whatever reason allow their opinions or experiences to be traced to their Dreamwidth identity as far as the public is concerned) but would also allow the people moderating the discussion to confirm at least relative identity. (In a recent high-profile discussion, one person in the publishing industry was accepting comments by email to post anonymously with a description of that person's authority to be saying what they said.) It would also allow people to correct typographical errors or delete things that they had second thoughts about.

The commenter would have to trust that the journal owner/admin would not "out" them, which could be done deliberately (think screenshot), accidentally (referring to a person by name in a reply), or inadvertently (using information that they didn't think would be identifying, but was known to a third party witnessing the discussion). The commenter would also have to be careful of not sharing sufficient information to out themselves, and not anon-failing (posting fully identified in a forum where they had previously been posting anonymously).

This would be a possible workable way of allowing anonymity into locked entries. The usual problems with allowing anonymous comments on locked entries are mostly social - the journal owner would know that it's a small pool of potential commenters and can play matching games; the entry might be restricted to a very specific security group, such that someone might think themselves anonymous and comment, but could be the only person in the security group and therefore identifiable. However, with knowledge that their identity is visible only to the journal owner/admin(s), someone could comment "anonymously" with a more informed mindset (though fellows in the pool of people given access might still figure them out based on the fact that access is listed in the profile).

This would be great for anonymous games (anonymemes, kink memes, darkrooms, the pride thread). It would preserve accountability while retaining at least some part of the anything-goes spirit.

This was inspired by a locked discussion about drug use and abuse, which could possibly have used a feature like this. We're all there because we know the journal owner, not because we trust each other necessarily.

Description:
This suggestion is inspired by fiddlingfrog's suggestion on LiveJournal, and I thank him very much for bringing it up there. http://suggestions.livejournal.com/1085295.html #Dreamwidth IRC was also helpful in sorting out quite a bit of this.


Add identicons as another option for journals that allow anonymous comments, but don't necessarily want completely anonymous comments. This could be instead of, or in addition to, directly logging IP addresses for the journal owner to access. For visual users, an icon can sometimes also be more immediately recognized than an IP address.

Completely anonymous comments would still be available for places that require them, such as anonymous games (fic memes, anonymemes, love memes) and journals who wish to allow the totally anonymous comment experience.

For users who would like to attempt to tell anonymous commenters apart to the extent offered by IP address logging, but without actually logging IP addresses of all anonymous commenters, using an identicon could be a useful compromise.

The use of identicons in a journal should be disclosed to potential commenters similar to the way that IP address logging is disclosed, so a commenter may make their own decision prior to commenting.

Identicons on otherwise completely anonymous comments could be displayed to all visitors to that entry.

Identicons on comments that had their IP address logged could have the identicon displayed to all visitors, and continue to have the IP address displayed to only the journal owner.

The same identicon could be used all over the site for the same IP address; fiddlingfrog suggests that to provide a little more anonymity for anonymous users in different contexts, that the identicon could also use journal information (same identicon for same IP all through a single journal, but different in each journal) or even by entry (same identicon in one entry but different in the next, even in the same journal).

When "named anonymous" commenting is implemented, identicons could be created based on name, email address, or external journal location, to add visual interest to the comment space. Named anonymous commenters might be able to choose for themselves whether to use an identicon.


Should journals that use identicons log the IP address in a place where it could be accessed by appropriate site administrators (staff, Terms of Service team), but not the journal owner?

Identicons, or lack thereof, would make no difference to the anti-spam team.



What are identicons?

Identicons are little pictures based indirectly on identifying information. The identifying information (IP address, email address, etc.) has been passed through a process that mangles it non-reversibly while still keeping it most likely unique. If the same data is presented to the process a second time, it should come out in the same mangled format as the first.

Once the identifying information has been mangled into something equally unique, but no longer identifying (for example, an IP address that has been mangled can't be used to locate someone's Internet Service Provider or rough geographical location) it can be used to create an image, or maybe a sound file, or maybe just served up raw if there's no better way to get the information to a user in a form that's accessible to them.

Wikipedia article on identicons: https://secure.wikimedia.org/wikipedia/en/wiki/Identicon


Possible confusion:

Identicons do not provide any more continuity of identity than the source they are derived from. An identicon that is derived from an email address is likely to be the same person, so long as that person does not share their email address with anyone else, and so long as they keep the same email address.

Identicons derived from IP addresses have the same problems with matching comments to their actual human author as IP addresses, but without the additional helpful information that can be obtained from an IP address. Three anonymous comments coming from three different IP addresses that belong to the same internet service provider and are assigned to the same local area might actually be the same person. Since identicons cannot be reverse-engineered to reveal the originating IP address, the same three comments would have different identicons and might not be suspected to be the same person.

An identicon that is based on an IP address would only indicate a single person so long as the same person had one IP address and no other, and did not share it with anyone else commenting. If multiple anonymous users (say, from the same household at the same time, or same general geographic area and internet service provider at different times) commented and had the same IP address when commenting, they would be issued the same identicon and might be mistaken for each other. A single person might comment from home, comment from work, comment again from home after rebooting their cable-modem, and have three different IP addresses and therefore three different identicons.


Specific implementation suggestions

The "Vash" (visual hash) identicon generation engine is free to open source projects with a GPL-compatible license. Dreamwidth's code is licensed under the GPL + Artistic license. This particular implementation of the concept is aware of quite a few accessibility needs and is willing to work with projects if there are additional needs that their product does not currently support. If identicons are different for each journal space, the journal owner could conceivably provide settings to make identicons in their own space best suited to their own needs. http://www.thevash.com/index.html http://www.thevash.com/docs.html#faqs

Description:
For people who get plain text comment notifications and read their comments primarily in email, and load the site only when replying, this would be helpful in not missing nuances of the conversation being carried out in icons.

It is now easier to include icons meaningfully in text notifications because of the icon description field (though visual users using a graphic browser can still load the page and see the icon for themselves). The keyword used to select the icon should also be included, as this can provide some nuance in why that particular icon was chosen. If the comment was not chosen by keyword, the description should still be included: while many people know their friends' default icons by now, it may be a stranger commenting, or someone may have a new default icon.

This gives better historical context for people who save their comment notifications, as sometimes people change their icons. Rodney McKay viciously removing stupid obnoxiousness is a much better pair with a rant about Not Being That Guy than a mostly-unwrapped Pretty Young Thing.

The addition of icons can change a conversation: for example, "I see" is fairly neutral. A positively themed icon would make it unambiguously positive; a "FAIL" icon would make it unambiguously negative, and might push the conversation over the line where a community administrator might want to step in. (This situation happened years ago, but I remember it vividly.)

This would also be useful for comment edits: sometimes people (like me) edit their comments and only change the icon, and forget to put an edit reason. This results in the same text, without explanation, being sent in the emailed text notification of the edited comment. An observant recipient is probably going to figure that it was an icon edit, but including icon information in the notification would be helpful.