I just can’t see how delivering a Mine! URL containing a feed of my current possessions, to a form on an insurers site – means the insurer’s form isn’t vulnerable to being spammed by bots. However, I will go and think further as to what you’ve said, after reading again, and writing the rest of this comment as to how I feel a Mine! should work – I need to get this out of my system somewhere!

The main reason I bring this up, is that the way I see it, the Mine! needs do both; produce and consume for user experience and to help adoption. Not just produce and require manual labour (feed delivery) as I understand your Mine! does.

If there are no tools to consume the Mine! feeds, ensure their reputation, or find services that can take them from the get-go, who will implement and market it? On the other hand if my Mine! could talk to your Mine!, and your a freelancing graphic-designer whose services I’d like a quote from – one users Mine! could then produce a feed of structured requirements, and the other consume depending on which way the transaction needed to happen. This way user-driven relationships can be established immediately, no separate app to consume the feeds and therefore a much lower barrier to entry. Thereby helping adoption, because individuals become empowered to both manage & share their personal information, and- if they choose to – become a provider and recipient of users structured content. Both sides just needing to install a Mine! from the get-go. If they want to customise it into their business process, or write their own, they have a template they can work from, aka “stand on the shoulders of giants (your standard implementation)”.

I understand you wanting to keep this as simple as possible, dishing out just feeds with structured content from the Mine!. Why my thinking is that AtomPub is a RESTful(like) API, so why not publish insurance quote feeds to a service providers Mine! using the AtomPub API, instead of a form on a website? Additionally, have a service providers Mine! publish a feed with structured content for services it provides, such that consumers can find Mine! service providers to give feeds to. This would work by having a service provider Mine! ping aggregators with service updates. Consumers then subscribe to service aggregators by category in their own Mine! in order to learn of new company offerings, and also to bookmark them for later. Not unlike how feedreaders and blogs work now. Services could publish document structure they support in their feeds, and standards would emerge from that experimentation for different kinds of services saying what they want and users saying what they’ll give. A drag-and-drop interface like Yahoo pipes used by users to mix and match structured Mine! information to produce compatible feeds. And just like Yahoo Pipes, these compatible feeds could be saved and shared, with standards rising to the top based on a zeitgeist of users supported Mine! document structure, again in a feed. This way the service providers can publish the structure of data they want either privately or publicly, and users can choose to respond with a list of supported public & private feeds, thereby creating a standards market conversation.

I must be way off Mine! track by now…

While I think it’s mostly a great idea, I always like to flip great ideas on their head and attack potential weakness.

My cats used to do that to each other, too; it’s so *cute*.

While it may or may not be a big concern in the domain of insurance, I’ve been wondering about the potential cost of broadcasts such as RFPs, RFQs [Alec's ENVELOPES] , RFIs on service providers.

Errrr… I am afraid you have the wrong end of the stick, there; I don’t think you get what the Mine is about.

It’s a place where a user can upload their data, crunch it a bit – tag it, poke it, prod it, format it, whatever – and then then may elect to share it by means which I will detail in a future posting, but which at the bottom line mean “sharing the URLs for those objects with the third parties who may be interested in them”.

Thing is: you don’t want to have to share the URLs of (say) 400 objects separately and individually with the aforementioned third parties, so instead you wrap the URLs up in a blob of data and share the URL for that with them, instead.

The previous paragraph describes equally well a “feed”, or alternatively some manner of “container object” (something to which I was alluding by the word “envelope”) – so I should not need to describe it much further.

Curious as to whether you’ve thought about combating SPAM RFQs, etc that only waste a service providers resources. Is there a transaction history and reputation side of this utopia or will automation and honeypot filtering – just as we do with email – become a domain specific necessity?

Utopia? Dude, this is a tool and a phenomenon, not a hype curve. Also, most of what you are saying is not applicable to the model – “spam” is not possible in a Mine environment, for instance – so I have no idea how to respond to you.

And in a Mine! environment all notions of reputation are those of the user – eg: if I think someone’s crazy, I elect to avoid them in future. End of story.

If someone deals with me and decides that I am a bad debtor or something, then the world already has mechanisms to deal with that sort of thing. End of that story, too.

[...deletia...]

Enabling the Mine! app itself to search or crawl for service providers

You’re thinking about “agent-based computing” or similar. That’s not a Mine thing.

[...deletia...]

I think the most important aspect of this, is that everything be in one coherent idiot-proof interface.

Oh indeed.

If my mum has to think and leave her Mine! to deliver an envelope (URL) to some form, it’s too difficult.

I look forward to finding out.

- alec

While I think it’s mostly a great idea, I always like to flip great ideas on their head and attack potential weakness. While it may or may not be a big concern in the domain of insurance, I’ve been wondering about the potential cost of broadcasts such as RFPs, RFQs [Alec's ENVELOPES] , RFIs on service providers.

Curious as to whether you’ve thought about combating SPAM RFQs, etc that only waste a service providers resources. Is there a transaction history and reputation side of this utopia or will automation and honeypot filtering – just as we do with email – become a domain specific necessity?

I’m assuming both will be necessary more so in some domains than others, and that the Mine! Project may need to encourage 3rd party services to provide request/reputation management and SPAM filtering systems per domain.
Take your example, an insurer then only has to drop a 3rd party service form into their site and the third party does the rest, thereby lowering the barrier to entry for the insurer. Or perhaps instead of a form, as an API that can be automatically discovered using something like the recent /site-meta format proposal. Enabling the Mine! app itself to search or crawl for service providers, providers the Mine! owner could then simply click to either broadcast to, or send selective requests to providers by type, region, etc. Perhaps building a personal collection of providers in one’s Mine! such that owners could easily broadcast new and related requests to. Sites could display an r-button? to advertise Mine! support. Users then clicking to transact or just add the site to one’s Mine! to signify some form of relationship.

I think the most important aspect of this, is that everything be in one coherent idiot-proof interface. If my mum has to think and leave her Mine! to deliver an envelope (URL) to some form, it’s too difficult.

Craig.