25 August 2003

P2P Weblogs Here are some attributes that are a must for weblog P2P: The complete "active" network must be visible to all users.  This means that a single copy of a file on a single active node is an available resource to all users. Each file should be uniquely named and sourced. Each file must be verified for authenticity.  The P2P client software must be able to communicate with the weblog tool software using XML-RPC.  The P2P software should be invisible. The classic search feature of P2P systems should be disabled or unavailable.  The only way to access the files on the network is via a link on a weblog or via RSS subscriptions. Placing a file in a P2P folder should generate a unique URL that points to the location of the file on the P2P system.  This URL can be published in your weblog.  When someone clicks on it they will either begin the download (which is done immediately or delayed via preferences) or they are prompted to download the software. Files on the P2P network can be delivered as part of RSS enclosures. Multiple source downloads is a must. The P2P client should be cross platform. Optional:  Individual nodes can be turned off and specific files can be filtered.  If you have more requirements or disagree with the above, post them below. [John Robb's Weblog] 3:01:17 PM     Jeroen Responds and Neil Reresponds Payed Groovespaces. Neil Finlayson relaunches the idea of paid Groovespaces. Although i really like the idea i still think there some basic issues with the current version of Groove that make this idea difficult to implement. One is the sluggish behaviour of Groovespaces when they are flooded with users, chats and comments. Besides that, there is still no way to ignore a specific user meaning that once your vcard is known to a person, this person could easily stalk you with loads of unwanted messages which are much more difficult to ignore then normal spam emails. ... [Jeroen Bekkers' Groove Weblog] I hear you Jeroen. One approach to the sluggish performance is to clone and replicate among spaces as new users come in, such that the distribution of users per space never really gets much higher than the Groove design centre (30 or so?).  Dynamic, on-the-fly space creation is possible. Also sluggish is an engineering problem ... On spam - well I would say its a generalisation of the email spam problem. Its a tricky one but in essence no tricker than the situation we're already faced with in terms of our net identities being compromised. Groove.net is accessible to me right now with wildcards - why does the introduction of a space charge change this radically? Again its an engineering challenge. Filters and blocker tools based on Groove IDs anyone?  Groove enterprise servers would presumably evolve to cope ... but only if they were cheap enough for people to really use extensively and consider how to expand their capability. Lets return to the question of 'tipping point' - is it a reasonable proposition that the ecosystem would prosper and that Groove would gain users and suppliers exponentially from chargeable spaces? Would Groove space design become a growth industry like Web design was over the last 10 years?  Is expertise encapsulated in a Groove workspace a lucrative proposition? 2:07:59 PM     Paid-for Groove Spaces 'Paid-for spaces' would be anathema to some but I suspect it would translate into a tipping-point for Groove .... just as commerce vastly expanded the reach of the Web. I'm assuming the paid-for model would be reasonably easy to implement - especially if enterprise management servers were free or cheap rather than current horrendous price. Step 1. Go to web page and browse Groove paid-for service Step 2. Sign up and pay subscription fee Step 3 Enterprise Management server takes over registration and issues invite Step 4 Subsequent access to space managed by EM server ... Groove Networks should make it dead easy for this to happen, so the ecosystem can grow and be self-financing. 10:06:40 AM

© Copyright 2003 Neil Finlayson. Last update: 31/08/2003; 11:48:11.