…since the last update.
Alright, I admit it. Running a blog as a namesake domain is stupid. I’ve got work to show off that doesn’t fit in a blog post. Plus, blogging is no fun with your name so strongly attached. Turns into marketing and PR.
Therefore, I’ve started working on a new approach. Primary goal is posting new web work on-the-fly. Monthly rants shall be conducted elsewhere.
…invitees could generate invitations, forming a pyramid scheme. And the database records each invitee’s tier. Then you could do fancy things like set moderation privileges based on tier, or even show different content to different tiers. For example, 1st-tier invitees get to see all posts. 2nd-tier can’t see personal posts, unless I promote them. 3rd-tier has all images replaced with flaming skulls.
In other words, it’d be interesting to see hierarchical user roles assigned organically, and more granularly than either “Friend” or “Friend of Friend”. That only really works if you can keep track of when and how visitors start accessing a site. Thus, instead of Friending, the relationships between users would be governed by a hereditary invitation system.
Kinda like how we’re all stuck with weird family members who won’t eat wheat, hoard nativity sets, or spend Sundays postulating on Tumblr.
I’ve been thinking about how to limit access to a website as painlessly as possible. I’m not talking about real security — just privacy on the order of Facebook’s “Friends and Friends of Friends” scheme.
There should be some kind of email address validation involved, but not account creation. OpenID is alright, but I have reservations about using one, true identity for everything.* Plus, maintaining permissions on OpenID takes about as long as creating a bunch of accounts anyway.
Taking a page from Google Docs, let’s start with sending invitations via email. You could also work in a “request invitation” form, moderated by the site owner. The invitation email contains a link with a hash, matched to the invitee’s email address. So it looks something like: example.com/ievSVfrMq5wzBlH1.
Henceforth, that link works as long as the site owner keeps that invitee. But when the link is used, the server records the visitor’s IP address. Any subsequent visits from that IP address no longer require the hash. From then on, at that location, visiting example.com without the hash works just fine.
So not only can return visitors access the site normally, you also have a running record of all the IPs each invitee whitelisted.
Yeah, IPs are easy to spoof. Yeah, if someone visits from, say, a public proxy or an airport WiFi, you have no idea who could be accessing the site.** But it’s still pretty good I think, as a password-less, somewhat validated mechanism; particularly if your audience isn’t very expansive or mobile.
*Granted, that’s exactly what happens when all your accounts are tied to the same email address.
**Periodically running whois on stored IPs would work. If you don’t like the location, delete the IP from the whitelist, and tar and feather the invitee who’s responsible.
Started: 12/12/09 4:45 PM
File activity complete.
Finished: 12/12/09 4:45 PM
SVN: #155021. You cannot update this file using Dreamweaver’s Subversion integration because a newer Subversion client application on your machine has made updates to the file’s Subversion meta data. For more information on this issue, see http://www.adobe.com/go/dw_svn_en.
Locking everyone into one version of one client kinda defeats the purpose of VCS, wouldn’t you say? Yes, I’ll definitely work through all this bullshit to compensate for Adobe’s halfassery.
BTW, that “newer Subversion client” is Snow Leopard’s stock SVN CLI.
Recently reformatted and had a hard time tracking down these Terminal commands:
defaults write com.apple.spotlight DictionaryLookupEnabled NOdefaults write com.apple.dashboard mcx-disabled -boolean YESdefaults write com.apple.dock pinning -string enddefaults write com.apple.dock single-app -bool truedefaults write com.apple.Safari TargetedClicksCreateTabs -bool truedefaults -currentHost write -globalDomain AppleFontSmoothing -int 2defaults write com.apple.finder _FXShowPosixPathInTitle -bool YESdefaults write -g NSNavPanelExpandedStateForSaveMode -bool TRUEdefaults write -g PMPrintingExpandedStateForPrint -bool TRUE