It occurred to me, mulling this over, that the hosting mechanism for the platform is a fundamental issue and needs to be seen as a requirement, not an afterthought.
How one reaches a decision on this however is also dependent on whether the platform is intended for actual contributing members of a TT group somewhere in the world, or "all comers" who may eventually be using it for locating local services that support the local currency, or perform currency transactions or authentication. The latter issues will require support for potentially huge amounts of traffic if transition is a success.
Central hosting would make things much simpler. There's one website to maintain/update/debug, you can scale it using Amazon's EC2 compute cloud, etc.
However this goes against the spirit and the actual requirements really, of local transition groups. Where's the resilience if you use centralized Amazon EC2 or some other scalable compute cloud / ISP? Who knows if Amazon will even be trading post peak-oil - the energy costs of data centres will at least send the costs through the roof, perhaps making elastic computing a bad proposition anyway (funding of hosting for a high demand scalable global website is yet another issue to discuss). Who's to say free/cheap/reliable internet access will be available internationally 24/7 after peak oil?
So ideally one would have individual sites running the local "copy" of the platform, dealing with only their local data, but the published documents with global relevance available globally (albeit perhaps by a resource constrained internet conection). These could even run off local networks (a revival of local ISPs previously wiped out by the majors and "virtual ISP" market?), or ad-hoc wifi networks or perhaps Wimax or some as yet not invented high speed mid-range wireless net.
There are several challenges with this however:
1. It means local people have to be able to set up and maintain (and backup) the system
2. How would such a system scale up to handle high local demand / local currency implementation etc
3. It means the environment in which the system would run would be unpredictable
The above, in my opinion is a recipe for disaster, unless some smart - and probably technically complex solution.
A total brainfart at the moment, but I could envisage a peer-to-peer local networking system with virtual machines like Amazon EC2, a sort of mishmash of something like Seti@Home and VMWare/Parallels that would mean that adding capacity would just be a case of someone else in the local area with (local) net access plugging in a PC/Mac and running the application that does the peer-2-peer and virtual machine bootstrapping and network management.
It would be far more flakey than Amazon EC2 or similar... but can we actually rely on a global ISP?
Or do we just consider how to get TO peak oil, with as much activity beforehand by local groups, and hang the consequences for what happens after it all hits the fan?