Tim Knip's Groovey Weblog

Let's continue the conversation.................

Suite75 / Tim's experiments

I think can describe them better then i can

Integration scenario's

Public Groovespaces

Not all groovespaces will have the need to be private and secure but do have the need for some form of control .

Re: Public Groovespaces

> Not all groovespaces will have the need to be private and secure but do have the need for

Re: Public Groovespaces

Does the collaboration become more dynamic and spontaneous, and afford "better" integration with blogspace if groove users can publish selected Groove services (i.e. components or data within Groove), as opposed to having it be an all-or-nothing decision?

Re: Public Groovespaces

> Does the collaboration become more dynamic and spontaneous, and afford "better" integration with blogspace if

> groove users can publish selected Groove services

In theory. In practice, it will be very hard for people to manage the public/private boundary on a per-item basis. Psychologically it's better -- I think -- to be in one place or the other. This raises questions about Michael Herman's notion that a space that has "matured" can simply float to the Net. Are you sure everything in that space should go? If not, how would you decide? You'll find yourself doing an item-by-item inventory, trying to see what is or is not appropriate. I'm sure this will be way too much overhead for almost everybody.

Re: Public Groovespaces

I don't think a all or nothing option for a space is the right direction although i can imagine that you want to autopublish the contents of one tool.

Re: Public Groovespaces

At the risk of getting into implementation details, which I'm generally not good at, what obvious UI actions are provided to the user at each level of granularity. For example, 2 extremes - 1) A button option to publish the contents of a shared space into blogspace, 2) ability to right click on a particular object (i.e. a single discussion entry, or a single file) and publich only that to blogspace. Of course, many shades of gray in between. Would this be overly complicated to the user? Or could it be done in such a way that employed UI actions that most users are already comfortable with?

genereally i think you should be able to specifically select the content you want to have published and the rights for publishing can be granted to a group of people (admins) within that space only if needed.

Re: Public Groovespaces

From an overall architecture perspective, I challenge everyone to think laterally and also include other center-based web collab solutions like Yahoogroups (e.g. http://groups.yahoo.com/group/decentralization/).

Cheers,

Michael.

> some form of control .

Right. And this becomes a hard UI challenge if the rule for publishing is anything other than all-or-none. The minute people have to think about managing the public/private boundary on a case-by-case basis, it becomes way too much decsion-making and micro-management.

Imagine if we ruminated in here for a while and then arrived at some kind of consensus. Publishing just the parts of the space approved for public viewing would be, in the end, as easily accomplished by cutting/pasting selected material to some other space or straight to a blog.

OTOH, we could make the whole space public for viewing, but writeable by invitation only. I think that is an important use case. However, the extra degree of formality we'd expect of ourselves if these were a public space would undoubtedly impede the spontaneity of collaboration.

Re: Public Groovespaces

>>you can tink of a groovespace that will have all, or allmost all it's content published on the internet for people to read but only the member in the related groovespace can edit this information collaborative.

Yes, sounds like EasyWeb, partly

(fyi, EasyWeb is something I built a while back Cabezal EasyWeb Publisher.url but which is now unmaintained; Groove Networks owns the codebase). EasyWeb was oriented around publishing "websites", so one central piece was a templating system which could move Groove content into HTML (or XML of various flavours). It also had a "hands-off" publishing model: you set up the publishing parameters, and thereafter everything you do in the Groove space is automatically published up to your webserver.

That model may not be ideal: I was having this exact conversation earlier (with people at www.uprizer.com), and the use cases for integration with their stuff (effectively a distributed webserver) seem to be more relevant if there's an explicit "Publish This" button. The type of process I'm imagining is a content-creation activity in Groove: people getting together to create or refine a "document" or video or presentation or whatever, then having an "off-ramp" which can take one or a few specific pieces of Content back out of the Groove shared space.

Re: Radio integration: "publishing" (collaborative authoring) is only a part of the story. Necessary but not sufficient :-)

...sounds like EasyWeb?

you can tink of a groovespace that will have all, or allmost all it's content published on the internet for people to read but only the member in the related groovespace can edit this information collaborative.

Collaborative content management for newssections of websites etc.

Just a simple example but one that could get many people within a company into trying Groove:

update the newssection of your companies website or any other need for collaborative content management.

research , rewrite, add , edit and discuss items togehter in a secure space and only publish selective information to website.

Publish Spacereports or questions to an intranet

More secure and companywide to quickly find answers and/or people for specific issues

Experiments thus far

- use of Blogger API to send/edit posts to blog (blogger/RU)

NewsClient

More history from my back pocket. NewsClient was written at Agora, then maintained by Cabezal for a while, and now back with Agora. It's an RSS newsreader, in Groove.

NewsClient and NavigateTogether

Should be reasonably straightforward. The bigger question is: who has the time/motivation to do it :-0)

Re: NewsClient and NavigateTogether

I guess the question would be: since the NewsClient seems to share componentry with, say, the Discussion tool, why wouldn't the framework just give you that capability "for free"?

Shared componentry

Most of the newsclient is really different from the discussion and other tools; the list-style UI is the native Groove dataviewer, but the rest of the UI is mostly IE browser embedded (and the nice Flash piece), and custom spaghetti-gluecode.

There's also a prototypical "comments..." feature inside the newsclient tool (unfortunately we never really finished it properly). The idea here was that comments marked "public" would be re-published to a "community server", and the community server would publish its commentary as RSS, which other people (in separate Groove spaces, or in other aggregators) could subscribe to... (!)

Re: NewsClient

It would be nice if the NewsClient didn't trigger the unread mark at the shared space level.

Once NewClient is installed, the shared space is effectively always in an "unread" state from that point on (assuming a reasonable flow of RSS ... a 1-2 or more per day).

Michael.

NewsClient tool.url

Functionality: everything you would expect from a simple aggregator. No more.

- connect from Groove Tool to Radio using SOAP

>> if there's a SOAP-handler available in Radio, i can connect to it from Groove

>> when Edge Services is released: Radio could have macro's, scripts etc. connecting to a Groove-space: harvesting subscriptions news etc.

General question for Jon

Jon, obviously the rest of us in this space are heavy Groove users. Do you use Groove intensely? If not, what do you see as barriers? Does it have anything to do with a perception (right or wrong) that Groove is a closed box?

Re: General question for Jon

> Jon, obviously the rest of us in this space are heavy Groove users. Do you use Groove intensely? If not,

"Activation threshold"

Good term.

Re: "Activation threshold" - actually a design flaw in the Onramp

Re: there's a social threshold to cross before you press it.

Re: "Activation threshold" - actually a design flaw in the Onramp

This is also the same issue with the 1:1 Chat in Groove - my MSN Instant Messenger really is "instantaneous"; Groove IM is not.

Re: MSN messinger is more instantaneous but less secure.

I would like to understand how Messenger is "less secure"?

Re: MSN messinger is more instantaneous but less secure.

As far as I know the data is not encrypted. Anyone with a packet sniffer can read the data because its in the clear.

Re: MSN messinger is more instantaneous but less secure.

Additionally the passthrough msn messinger servers can be set to keep logs. The logs are not incrypted. Conversations from these logs have been supined by the courts and have shown up in court cases.

Groove incryptes the message on the client and transmits incrypted messages to the passthrough servers so the logs are not as easy to record and thus less likely to be a piece of evidence in some legal battle.

ssd

please forgive my spelling deficiency

From a pure technology perspective, I understand why Groove is "more secure" but Groove has it's own requirements for relay caching of deltas, etc. where Messenger does not.

How/why should I worry about my Messenger conversations being intercepted?

Michael.

MSN messinger is more instantaneous but less secure. I switch to groove when the level of secrecy is great enough to sacrifice the loss of speed and emidicy. The security model is a significant part of what makes groove work for me. Only port 80 and incription on both sides. Groove is one of the only apps I never allow for the password to be rememberd because Now It is the place where I share my closest held secrets with different nodes of my network of influience.

I had to sometimes go to the cmos house and install it myself but now anytime I can have his ear and thus have more influence.

Radio is more broadcast reputation managment. If dave tells me I should pay attention to Jon I do or atleast give it more time than I would because I go to scripting.com becasue of the celibrity reputation of Dave and the way he hand out or mediates annamous online reputation of thought,.

ssd

IMHO, this is actually flaw in the Onramp (and to a lesser extent Groove Workspace) because the current design runs out-of-process (Outlook relative to Groove) and because an entire shared space needs to instantiated. It's horrible to use.

This is also the same issue with the 1:1 Chat in Groove - my MSN Instant Messenger really is "instantaneous"; Groove IM is not.

(but at Parallelspace, we're fixing both of these with a solution to be released real soon :-)

Cheers,

Michael.

Even if you're an Outlook user and the Groove onramp is installed, there's a social threshold to cross before you press it. ("Will people ignore this? Is everyone using Groove? Is this the right thing to do - my boss is on the copy list?" etc.)

I'm not an Outlook user - my main email has been Notes for years now, and I could really use an equivalent onramp button there - but even now with people inside Groove Networks I often start a conversation in email, rather than starting in a Groove space. If you're copied on an exploratory email, it's easy to "lurk". If you accept a Groove shared space invitation, you might get more context than you need.

So, although I think Groove's incredibly strong in positioning as "ten times better than email" (because it solves all the horrible things about decisionmaking-by-email), it will get a higher rate of traction where the OnRamp is a more "vertical" application. My ancient "CPC" pitch (http://www.cabezal.com/ppt/CPC.pdf) opens some of those application ideas. Recently I've been involved with a couple more: an Autonomy onramp which gets context (and people) into shared spaces when it's been identified as a "cluster" by their content analysis technology; a project-management onramp which gives you a new shared space to fix the problems which are making your milestone slip. Both of those are Web-triggered (click a hyperlink to get a new Groove shared space): the hyperlink is not the space, it's an option on the space (per dpr_ options.url ).

Q: Is there a "Radio OnRamp"? What should it be for?

Permeable public/private boundaries

You say "My conclusion is that Groove needs to find ways to make the public/private boundary more permeable... seems to go against the very bedrock principles on which shared spaces are built..."

a non-debate, imo

See Space defintions (andyswarbs -PopG2#3) where I begin to argue that Groove or whoever should just get on on and do it.

- I don't think you have much reason to worry about Groove's principles here. We have a few guiding principles in how you should look at permeating that boundary (for example, that participants in a shared space should always be aware if their actions will be visible beyond the boundary of that private shared space), but not about whether it's a good idea!

NNTP is almost the opposite case: so open that many public newsgroups suffered the "tragedy of the commons" with spam, but incredibly elegant in managing "multiple collaborative scopes" (your term, which I just read...!).

Some prior rambling of mine (again) - http://www.cabezal.com/ppt/soft_edges.pdf

Re: General question for Jon

Jon may appreciate this thought most.

mind of Dave / mind of Ray

You may well be right.

Where that leads us, I am not sure :-)

Radio and thus Frontier is somewhat of a self-portrait of the mind of Dave Whiner. Dave is the center of the node that broadcast to lots of people. I met Dave through Mason Hale who I think wrote the first cgi framework for frontier thus making it web enabled and allowing dave to reach and interact with a much wider community of like minded people. I always have trouble understanding frontier and radio because my mind is not like an object database. I have difficulty with the mental model or sense making exercise; in time I learn enough functionality to get my task done usually with help from Mason.

Now I have never met Ray Ozzie but I understand him deeply. Mostly because Groove is likewise a self-portrait of the mind of Ray and it makes sense to me. Groove is about sharing secrets. Most of the work Ray does with three people one being his brother. He and I are deeply private people but span the holes in our social network. I read scripting frequently and pass on things to other nodes in my network often using groove as the information transport.

I have installed more groove trial versions than anyone I know. I depend on the alert icons to see the horizon of my network.

If we can get ray and dave together in a social setting and watch how they integrate that is the way we should approach the integration of radio and groove.

Stephen Dulaney

> what do you see as barriers? Does it have anything to do with a perception (right or wrong) that Groove

> is a closed box?

No I don't use Groove intensively, but not because I don't want to. I would like to use it more, but in my day-to-day professional intercourse I do not find other Groove users with whom to collaborate. This may change now that I'm with InfoWorld, since folks there do use it (I'm told). We'll see.

This has been a longstanding concern for me. I first saw Groove in beta when Tim O'Reilly invited me along for a visit to the company, in (I guess) May of 2000. I loved it of course, but I was immediately worried when I saw how it was not connected to the primary mode of collaboration, email, and also only indirectly connected to the web.

Still, I considered whether to evangelize Groove in the same way that I had years earlier evangelized private NNTP collaboration (which was and remains incredibly powerful, although nobody much cares). In the end, having felt burned by the failure of my own Internet-style approach to catch fire, I decided to take a wait and see approach. So I waited to see who would send me an email with a Groove injector.

Despite the fact I was an author of the Groove chapter in the ORA P2P book, and elsewhere visibly writing about Groove, nobody ever invited me into any shared spaces. Nor has this changed (so far) with the availability of the 2.0 Outlook on-ramp.

If I had not specifically and publicly arranged to get myself invited into this space, it would not have happened.

My conclusion is that Groove needs to find ways to make the public/private boundary more permeable, and find even more aggressive ways to lower the activation threshold for transitioning into Groovespace. I completely appreciate how difficult this is, given that it seems to go against the very bedrock principles on which shared spaces are built -- the reasons for which I understand and agree with. (It was, after all, the security chapter of the P2P book which I helped to write.) The concept of a "public shared space" seems, on its face, to be utterly un-Groovelike.

I hope that we will all discover, over time, that this concept could make sense. And, that we can articulate more clearly how and why.

Technote: "E-Mail Discussion List and Groove Shared Space"

I've just joined this discussion and wanted to tgrow out a few things I've been thinking of ...before I get assimulated :-)

One parallel area of thinking I've been working on is how to motivate and gradually migrate a web/email based discussion group (e.g. a Yahoogroup in the technote's example) to a Groove-based solution. Checkout http://www.parallelspace.net/ddd/.

Weblogs aren't really significantly different except that they're 1:many. Caveat: Jon and Dave Winer just got me started using weblogs at the ORA Emerging Technology conference last month. Checkout: http://parallelspace.blogspot.com/.

Michael.

Why not create a Personal Publishing Server as a Groove tool?

Checkout http://parallelspace.blogspot.com/ where I begin to describe an HTTP Service Groove tool that allows you to selectively publish the contents of a shared space ...a discussion that I started in the Chat window for this tool but no one else was online to chat with. :-)

Re: Why not create a Personal Publishing Server as a Groove tool?

I was just thinking about this too I think...

Re: Why not create a Personal Publishing Server as a Groove tool?

A Groove Tool can check the RSS-feeds living in someone's copy of Radio (one condition: a RU-user has to install a Web Service making this possible. >> no big deal: just copy a txt-file to RU's Web Services folder).

Simple to get these items from RU...

So if one would accept Radio as 'backbone', all stuff described in this thread is possible with ease:

- publish stuff (opml, rss) from Groove to RU

- get stuff from RU into Groove

And... sure, all this can be done also using a Groove Tool as Personal Publishing Server, or dumb FTP, or use IIS Personal Webserver, or...

Re: Why not create a Personal Publishing Server as a Groove tool?

Another thought: Edge Services

a user makes a SOAP-call to some Groove-Tool to request some data...

Sounds like a WebServer to me... No need for another one?

What if we provided a way to leverage the invitation mechanism for subscribing to an RSS feed. So I could expose something like the discussion tool, in rss format (or opml) but unlike Radio, where I have no control over who is subscribing to it, I could get an IM when someone tries to do this, and then approve or disapprove them. I don't know... now that I write it down it doesn't seem that useful. But Matt's post about the asynchronous nature of Blogs got me thinking in this direction. Because Radio does have RSS subscriptions, so in essence you are notified when a Blog you are interested in changes.

I too have to learn more about Radio, since I really haven't had any time to play with it at all, other than the OOTB functions.

...kind of like EasyWeb but have the tool itself expose an HTTP Service ...perhaps like Radio (but I'm not familiar enough with Radio to really make this comment).

Michael.

Shared Space Chat Archive 020605 (Is this the same as a blog? ;-)

Tim Knip/Suite75: 6/5/02 10:48 AM

Re: Shared Space Chat Archive 020605 (Is this the same as a blog? ;-)

If the chat was archived in this way and then removed from the main chat area, should a link to this item have been left behind in the chat? Just curious, I'm not completely up on the protocol for this kind of thing, and was puzzled to see the chat had been truncated.

Re: Shared Space Chat Archive 020605 (Is this the same as a blog? ;-)

Good point Jon ...even from the perspective of simple etiquite. (I wonder when Groove will get a spell checker .... ;-)

I didn't know this chat archive above

Chat Archives (andyswarbs -PopG2#3)

yo!

Jeroen Bekkers/Suite75: 6/5/02 10:50 AM

yo

Tim Knip/Suite75: 6/5/02 10:48 AM

http://www.xmethods.com

Tim Knip/Suite75: 6/5/02 10:48 AM

check available webservices...

Jeroen Bekkers/Suite75: 6/5/02 10:51 AM

ok

Tim Knip/Suite75: 6/5/02 10:50 AM

hehe, kan ik nu allemaal gebruiken vanuit groove

Tim Knip/Suite75: 6/5/02 10:52 AM

maar goed... nu eerst een toepassing verzinnen...

Tim Knip/Suite75: 6/5/02 10:54 AM

maar tof hoor, google api: search, spelling-suggestion etc

Jeroen Bekkers/Suite75: 6/5/02 11:02 AM

just invited Jon Udell

Jeroen Bekkers/Suite75: 6/5/02 11:05 AM

just invited Hugh Pyle

Jeroen Bekkers/Suite75: 6/5/02 11:05 AM

Hi jon

Jon Udell: 6/5/02 11:04 AM

Hi Jeroen and Tim

Tim Knip/Suite75: 6/5/02 11:04 AM

hi Jon

Jeroen Bekkers/Suite75: 6/5/02 11:06 AM

hi, i thought let's open this space to discuss some integration scenario's

Jeroen Bekkers/Suite75: 6/5/02 11:07 AM

Tim has been doing some nice experiment to integrate Groove and Radio and we feel it's a powerfull combination

Tim Knip/Suite75: 6/5/02 11:05 AM

with upcoming Groove Edge Services, integration could be compelte...

Jon Udell: 6/5/02 11:06 AM

Can Tim's work be demonstrated here?

Tim Knip/Suite75: 6/5/02 11:06 AM

I have to make a tool first, hehe

Jeroen Bekkers/Suite75: 6/5/02 11:08 AM

hi Hugh

Jeroen Bekkers/Suite75: 6/5/02 11:08 AM

can you invite matt and John , i don't have their vcards

Hugh Pyle/Groove: 6/5/02 11:11 AM

Hi Jeroen - greetings from rainy England. (Dylan's happy, though - Ireland 1:1 against Germany!)

Tim Knip/Suite75: 6/5/02 11:07 AM

had to get to grips with SOAP, WDSL etc...

Hugh Pyle/Groove: 6/5/02 11:11 AM

Sure

Tim Knip/Suite75: 6/5/02 11:07 AM

hehe! last minute!

Hugh Pyle/Groove: 6/5/02 11:13 AM

Just catching up - back later

Hugh Pyle/Groove: 6/5/02 11:13 AM

I invited Matt and John

Jeroen Bekkers/Suite75: 6/5/02 11:11 AM

ok, thx,

Jeroen Bekkers/Suite75: 6/5/02 11:13 AM

Tim, can't we add an early version of the blogger tool ?

Jon Udell: 6/5/02 11:12 AM

I'd be very interested to see that.

Tim Knip/Suite75: 6/5/02 11:12 AM

sure, but it's not SOAP. Blogger Tool uses XML-RPC / Blogger API

Tim Knip/Suite75: 6/5/02 11:12 AM

blogger.com only...

Jon Udell: 6/5/02 11:13 AM

Why only blogger.com?

Tim Knip/Suite75: 6/5/02 11:13 AM

oops... description not found

Tim Knip/Suite75: 6/5/02 11:14 AM

it was start of exploration XMLRPC + SOAP

Tim Knip/Suite75: 6/5/02 11:14 AM

after succeeding using blogger.api started checking out SOAP

Matt Pope/Groove: 6/5/02 11:20 AM

Hello all

Jon Udell: 6/5/02 11:16 AM

FWIW, XML-RPC and blogger API are the most prevalent integration path in blogspace today. I regard the transition from that to SOAP as a relative non-issue. The big issue, to me, is how to construct a user experience that makes sense for conversations flowing between the two worlds.

Tim Knip/Suite75: 6/5/02 11:16 AM

Hi Matt.

Tim Knip/Suite75: 6/5/02 11:17 AM

y, Jon, I agree: I now have the knowledge to create an experience. Question is: what experience

Jeroen Bekkers/Suite75: 6/5/02 11:19 AM