More comments on the below

Kousik raised some queries and so have some of my friends when I talked to then irl.
So here goes some clarifications - note : I am pretty miserable at writing down ideas - so please bear with me !

Let me explain what I meant , and taking the the online marketplace as an example.

First things first :
The idea is not to come up with any replacement or alternative to a single vendor. It is not like a single vendor trying to push his network over others , etc. That sort of thing just wont get accepted - everyone thinks theirs is the best ;)

Now that , that is cleared , let us move on (this is a point oft mentioned to me !!)

Let us consider the online marketplace - more specifically , a bunch of buyers and sellers - here the term is used loosely - it could be buying and selling goods or services.
Usual cases are - you go to a site , advertise your wares (if you are the seller) or search through the advertised wares (if buyer) - and then negotiate on a price.
Negotiation could be by bidding , flat rate (no negotiation !) , offline negotiation (that is not within the purview of the marketplace ) or maybe other more complex domain specific forms.

Now , here the restrictive things are :
Every buyer or seller is exposed to only products or customers who belong to that network.
Someone else interesting in other similar network is not accessible.
I , as a developer , might have a better form of negotiation , etc which is not pluggable into this system since it is controlled by a single entity.
A new player in this field is stiffled even if he might have really cool service ideas , since he does not have the required userbase.
It is like vendor-lockin in a different sense.


What I was talking about was like this -
You have a base network in place on/over the web. (Network is used in the sense of a set of networked servers (server-set as i call it) - not a traditional network layer thingy ;) ).
Every user will have a id in the base network.
This id will be unique across all servers , clients (and service providers) - it will be his network id.

The idea is like this -
Consider a network which handles these :

a) User identification and verification (maybe certificate based , liberty based, etc).
Every user will be uniquely identified in the network and non-repudiation will be built into network.
b) Allow users to run queries for available services/goods/etc (whatever it is called) on the network.
(Think of kazaa query for doom3 :D )
c) Allow users to publish new offerings ,remove their current/previous offerings , etc.
d) Allow for basic notification mechanism - for a buyer to intimate a seller of his interest, etc.

So basically you have a network offering all the basic services required for a marketplace - I am using marketplace in the layman's sense , not in full-blown ecom sense.

Now consider an example.
A housewife wants to get her house painted.
She logs into the network with her id , sends out a query for a painter with required parameters (availability timeframe , rate range , location , etc).
She will get , as a response , all the painters who have advertised in this network.
These could have been through service provider portals , or direct publication to the network.
She can notify him with her contact info , or if the painter had put up the contact info , can directly contact him.
(The service providers might offer value added services in this regard).
You can have portals or service providers on this network , who can offer value added services like aggregation , ranking , authenticity , other market differentiators which use the underlying user base and features.
This way , you will never have vendor-lockin in the traditional sense.
You might keep visiting a service provider due to his value-added services or his market differentiators - but you can switch anythime without loosing your customer base as a seller or your potential seller base.
Also , a new players entry into market will be having minimal overhead and you might have lot of specialised vendors.


The network takes care of the actual search , user-validation (through signed requests) , publishing of requests , etc.
This is transparent to a developer writing the client , and it is going to be transparent to the service providers on this network.


Hope this clarifies some of the stuff I mentioned ! Please feel free to post comments - would be more than happy to have feedback on this :)

Some of the other things I was toying of include these :

a) The network of server-sets should be open - so that you do not have a single entity controlling the whole thing.
You should be able to plug in a new server anytime into the network and take it offline at anytime too !
There should be no info loss when doing this. We modelled this loosely as a staggered server-set in a hierarchical way.
(Rajesh suggested this loosely modelled on how dns works).

b) When a server goes down , connected clients to that server should not suffer and should be automatically connecting to other serversin that server-set.
Fault tolerance and security should be built into the network and would not be an after thought :)

c) Client type - We (more specifically Noble :) ) envision a thin client based client - there would be very minimal client side info storage so that you can have very light clients. Everything would be in a distributed form in the server-set.

d) The actual communication between the client and the server-set can be anything - http , direct socket , wml , etc.
The actual communication between servers will always be the same and assuming that they will be directly able to talk to each other.
This way , you can have different client types able to get into the network.
Like a guy with a wap enabled phone or a fat client - each talking to a corresponding server which understands that specific client protocol.

e) Value added services by service providers.
All the current marketplaces would be able to build on top of the base network to offer their services.
You can continue to use the base network directly , while these guys can offer more sophisticated solutions like specialisations for a particular domain , credibility ranking , etc.
This way , whatever you can do currently can be done using this network.

f) Noble was suggesting that the distributed nature of this system can be modelled by using juxta - this is not the time to decide things like this ! but he suggestion is with merits :)

g) The network as such would not be doing any content classification or interpretation - hence this base idea can be extended to other domains and services too !

Note - this is just an idea thrashed out by a couple of 'nutcases' here :D
Toying with ideas 'cos of our frustrations with how things currently are.
Need to not end up with an implementation !
Content aggregation from disparate networks to provide a unified view to the user (like froogle does) is masking the underlying problem - it is a workaround I feel and not the solution !! (I think this is what you were suggesting Kousik ?)