You are in the labyrinth/archive. Click here for the new


  • (none)

Viral Group Blog

created 2004-04-28 16:24:45

Idea: Generate a group blog, the membership of which constantly changes according to a simple invitation system. The make-up of the blog would depend on whoever was in it at the time, but would remain on some kind of "track" according to the semi-closed nature. Perhaps.

Here's how I envision it:

  • Person 1 starts the blog.
  • Person 1 can invite anyone the like to become a blog member.
  • If that invited person joins, they can blog stuff. They can also invite anyone they like.
  • If more than a certain number of people are members, then when someone joins, the oldest member gets booted off the blog. Hence membership "revolves".
  • That's it.

Notes and possible extras:

  • A person may only rejoin if asked to by current members.
  • So maybe have a list of previous members, and some basic stats (number of posts, number of times been a member, etc).
  • To avoid an oligarchy forming amongst existing members, somehow "force" them to invite new members - maybe have a timeout, and a "pool" of wannabes who get selected from if nobody accepts invites before that timeout.
  • May be necessary to put something in place to deter people from inviting themselves, although maybe this is a scalability/reputation-net issue, and may be avoided through numbers or clever username management.
  • Could have something so that when you post, you get put to the top of the list again, or your place in the list moves "up" one point, so those who post less are more likely to get kicked off.

See also...

Update to factor in has added support for e-mailing entries to the blog. Suddenly, this means I don't have to write my own blog software to get a Viral Group Blog into fruition - just the mail handling part. OK, I think it could work like this:

  • The secret e-mail to post to the blog is held privately on my server.
  • I have a semi-public e-mail that anyone currently in the Blog list can post to.
  • When they do so, and after their membership is validated, their mail gets forwarded to the blogger address.
  • I then just have to write some stuff handle invites, but the list manipulation can basically be a flat text file that procmail greps against.

Invites could work like this:

  1. Current blog member sends a mail to a "blog-invite@..." address. (Uses same validation file as above)
  2. Address gets added to a list of invited addresses, plus mail gets sent to address to let them know. Could also check against list of "requests" to auto-authorise someone who has already requested to be a member.
  3. If confirm/request mail (there's no real difference) gets sent to the server, then move the address from the list of "invited" to list of "members", and bump an old member off. If it's not on the "invited" list, add it to the "requests" list.

Still not sure if this encourages people to authorise themselves (at a different e-mail). Maybe this would just be emergent stability...

Another thought - need to pass the username of the poster into the subject of the blog post, too, as users are completely separate to the list maintained by procmail.

Problems (and Fixes)

  • If someone who is currently not a member knows the e-mail address of someone that is a member (say, if they invited them on, but have since been removed), they could spoof an e-mail from that address in order to invite themselves on/post to the blog.
    So... when someone confirms that they want to become a member (like confirming you want to join a mailing list), they mail their confirmation to "confirm-pass@...", where "pass" is a String/word of their choosing. This then acts as a kind of password, so they would then post to "post-pass@...", for example.
    This way, "protected" actions need a verified From address, and a matching To address.

I just hope this isn't getting too complicated. If the system is being run through e-mail, the commands need to be extremely simple, with good instructions too.

(See also: EMail As An Interface )

ckpoevtugba pxcbrighton