Just a little bit ago we opened the federation port for Google Wave's developer instance, so we can all begin experimenting with federating waves against WaveSandbox <http://wavesandbox.com/>.com <http://wavesandbox.com/>. Since that is the developer preview instance, please keep in mind that it is an experimental service, and it is likely that there will be unforeseen glitches in the coming weeks. Please share your progress here in the wave-protocol forum, so we can work through issues together.
Over the next several weeks we plan to add some important features to this service:
- TLS for XMPP: - The protocol itself specifies two distinct security mechanisms: delta signing and XMPP over TLS. Delta signing is required to be able to verify the authenticity of the source of the operations. TLS is an additional layer of security to the XMPP protocol, but it can be a bit hairy to configure. In order to encourage prototyping, TLS is not enabled on WaveSandbox.com, but it will become required in the coming weeks. This gives existing FedOne instances an opportunity to get signed certificates and configure their XMPP servers properly. - Reliable Delivery: - For any communication mechanism it is important that there is a contract for delivery of the message contents, and we are working on a reliable delivery mechanism from WaveSandbox.com.
With that said, to get started federating with WaveSandbox.com, you should visit the wave-protocol project <http://code.google.com/p/wave-protocol/> and review the installation instructions<http://code.google.com/p/wave-protocol/wiki/Installation>. If you have previously installed and configured FedOne to talk to other FedOne instances, you will need to upgrade to the latest revision (revision 08b5eecb93) to properly interoperate with WaveSandbox.com. For those of you building your own clients or servers, please take special care to review the documentation that describes the errata<http://code.google.com/p/wave-protocol/wiki/DifferencesFromSpecificat...> between the protocol specification and the current FedOne implementation between the protocol specification and the current FedOne implementation, and coincidentally, WaveSandbox.com.
As you are developing, please keep in mind we welcome contributions to the growing open source reference implementation; please check out this guide on submitting open source code<http://code.google.com/p/wave-protocol/wiki/SubmittingCode> .
On the specification front, the Google Wave Conversation Model draft specification has been revised and updated to include the blip document schema, which defines the representation of rich text necessary for proper interoperation with WaveSandbox.com. That document is available here: http://www.waveprotocol.org/draft-protocol-specs/wave-conversation-model
The updated specifications and FedOne code introduce new changes to the wave model, but they aren't the last; we expect more changes to come as we iterate with you on the implementation and learn from these early experiments in federation. Once the specifications and reference code have converged and become reasonably stable we will begin to federate wave.google.com, until then we have a lot of work to do. Looking forward to hearing your feedback.
I just set up my federated server over the weekend, so I suspect it may
be the latest. (I'm using Openfire and followed the install directions
linked to below). However, I have two questions.
First, how do I determine the revision? My build.properties tells me that I
am running fedone.version=0.2 but I can't find revision numbers anything
like 08b5eecb93.
Second question: I've set up my server, opened the proper ports, and
connected using the run-console-client from a remote machine. However, I
haven't been able to test with other servers yet, and I'm curious about if
besides finding other servers to federate with, there are things that need
to be done in the configuration or build of the server, or if it will just
federate out of the current build without any special configuration
concerns.
-----Original Message-----
From: wave-protocol@googlegroups.com
[mailto:wave-protocol@googlegroups.com]On Behalf Of Dan Peterson
Sent: Monday, November 02, 2009 1:18 PM
To: wave-protocol
Subject: Google Wave Federation Protocol port open on WaveSandbox.com and
Other Updates
Hi everyone,
Just a little bit ago we opened the federation port for Google Wave's
developer instance, so we can all begin experimenting with federating waves
against WaveSandbox.com. Since that is the developer preview instance,
please keep in mind that it is an experimental service, and it is likely
that there will be unforeseen glitches in the coming weeks. Please share
your progress here in the wave-protocol forum, so we can work through issues
together.
Over the next several weeks we plan to add some important features to this
service:
a.. TLS for XMPP:
a.. The protocol itself specifies two distinct security mechanisms:
delta signing and XMPP over TLS. Delta signing is required to be able to
verify the authenticity of the source of the operations. TLS is an
additional layer of security to the XMPP protocol, but it can be a bit hairy
to configure. In order to encourage prototyping, TLS is not enabled on
WaveSandbox.com, but it will become required in the coming weeks. This gives
existing FedOne instances an opportunity to get signed certificates and
configure their XMPP servers properly.
b.. Reliable Delivery:
a.. For any communication mechanism it is important that there is a
contract for delivery of the message contents, and we are working on a
reliable delivery mechanism from WaveSandbox.com.
With that said, to get started federating with WaveSandbox.com, you should
visit the wave-protocol project and review the installation instructions. If
you have previously installed and configured FedOne to talk to other FedOne
instances, you will need to upgrade to the latest revision (revision
08b5eecb93) to properly interoperate with WaveSandbox.com. For those of you
building your own clients or servers, please take special care to review the
documentation that describes the errata between the protocol specification
and the current FedOne implementation between the protocol specification and
the current FedOne implementation, and coincidentally, WaveSandbox.com.
If you don't have a WaveSandbox.com account, you may request a developer
account here. We hope to provision those accounts within a week or so.
As you are developing, please keep in mind we welcome contributions to the
growing open source reference implementation; please check out this guide on
submitting open source code.
On the specification front, the Google Wave Conversation Model draft
specification has been revised and updated to include the blip document
schema, which defines the representation of rich text necessary for proper
interoperation with WaveSandbox.com. That document is available here:
http://www.waveprotocol.org/draft-protocol-specs/wave-conversation-model
The updated specifications and FedOne code introduce new changes to the
wave model, but they aren't the last; we expect more changes to come as we
iterate with you on the implementation and learn from these early
experiments in federation. Once the specifications and reference code have
converged and become reasonably stable we will begin to federate
wave.google.com, until then we have a lot of work to do. Looking forward to
hearing your feedback.
On Tue, Nov 3, 2009 at 5:38 AM, Aldon Hynes <Aldon.Hy...@orient-lodge.com>wrote:
> Quick followup questions:
> I just set up my federated server over the weekend, so I suspect it may
> be the latest. (I'm using Openfire and followed the install directions
> linked to below). However, I have two questions.
> First, how do I determine the revision? My build.properties tells me that
> I am running fedone.version=0.2 but I can't find revision numbers anything
> like 08b5eecb93.
If you sync to the head of the repository, that is going to be best.
Actually, as I write this, I realize I made a mistake: that revision number
is no longer the proper revision -- as there were a few fixes that went in
after that. Please when you re-build, do a make clean before the new build
of FedOne.
> Second question: I've set up my server, opened the proper ports, and
> connected using the run-console-client from a remote machine. However, I
> haven't been able to test with other servers yet, and I'm curious about if
> besides finding other servers to federate with, there are things that need
> to be done in the configuration or build of the server, or if it will just
> federate out of the current build without any special configuration
> concerns.
Simply login to wavesandbox, and add f...@domain.com to a wave (where domain
is where FedOne is running) -- as long as you have the proper
CA-validated certificates setup, it should all work. You should also be able
to make a wave on your FedOne instance and add a participant on wavesandbox
to that particular wave.
> -----Original Message-----
> *From:* wave-protocol@googlegroups.com [mailto:
> wave-protocol@googlegroups.com]*On Behalf Of *Dan Peterson
> *Sent:* Monday, November 02, 2009 1:18 PM
> *To:* wave-protocol
> *Subject:* Google Wave Federation Protocol port open on WaveSandbox.com
> and Other Updates
> Hi everyone,
> Just a little bit ago we opened the federation port for Google Wave's
> developer instance, so we can all begin experimenting with federating waves
> against WaveSandbox <http://wavesandbox.com/>.com<http://wavesandbox.com/>.
> Since that is the developer preview instance, please keep in mind that it is
> an experimental service, and it is likely that there will be unforeseen
> glitches in the coming weeks. Please share your progress here in the
> wave-protocol forum, so we can work through issues together.
> Over the next several weeks we plan to add some important features to this
> service:
> - TLS for XMPP:
> - The protocol itself specifies two distinct security mechanisms:
> delta signing and XMPP over TLS. Delta signing is required to be able to
> verify the authenticity of the source of the operations. TLS is an
> additional layer of security to the XMPP protocol, but it can be a bit hairy
> to configure. In order to encourage prototyping, TLS is not enabled on
> WaveSandbox.com, but it will become required in the coming weeks. This gives
> existing FedOne instances an opportunity to get signed certificates and
> configure their XMPP servers properly.
> - Reliable Delivery:
> - For any communication mechanism it is important that there is a
> contract for delivery of the message contents, and we are working on a
> reliable delivery mechanism from WaveSandbox.com.
> With that said, to get started federating with WaveSandbox.com, you
> should visit the wave-protocol project<http://code.google.com/p/wave-protocol/> and
> review the installation instructions<http://code.google.com/p/wave-protocol/wiki/Installation>.
> If you have previously installed and configured FedOne to talk to
> other FedOne instances, you will need to upgrade to the latest revision
> (revision 08b5eecb93) to properly interoperate with WaveSandbox.com. For
> those of you building your own clients or servers, please take special care
> to review the documentation that describes the errata<http://code.google.com/p/wave-protocol/wiki/DifferencesFromSpecificat...> between
> the protocol specification and the current FedOne implementation between the
> protocol specification and the current FedOne implementation, and
> coincidentally, WaveSandbox.com.
> As you are developing, please keep in mind we welcome contributions to the
> growing open source reference implementation; please check out this guide
> on submitting open source code<http://code.google.com/p/wave-protocol/wiki/SubmittingCode>
> .
> On the specification front, the Google Wave Conversation Model draft
> specification has been revised and updated to include the blip document
> schema, which defines the representation of rich text necessary for proper
> interoperation with WaveSandbox.com. That document is available here:
> http://www.waveprotocol.org/draft-protocol-specs/wave-conversation-model
> The updated specifications and FedOne code introduce new changes to the
> wave model, but they aren't the last; we expect more changes to come as we
> iterate with you on the implementation and learn from these early
> experiments in federation. Once the specifications and reference code have
> converged and become reasonably stable we will begin to federate
> wave.google.com, until then we have a lot of work to do. Looking forward
> to hearing your feedback.
On Mon, Nov 2, 2009 at 8:15 PM, Dan Peterson <dpeter...@google.com> wrote:
> On Tue, Nov 3, 2009 at 5:38 AM, Aldon Hynes <Aldon.Hy...@orient-lodge.com>wrote:
>> Quick followup questions:
>> I just set up my federated server over the weekend, so I suspect it may
>> be the latest. (I'm using Openfire and followed the install directions
>> linked to below). However, I have two questions.
>> First, how do I determine the revision? My build.properties tells me that
>> I am running fedone.version=0.2 but I can't find revision numbers anything
>> like 08b5eecb93.
> If you sync to the head of the repository, that is going to be best.
> Actually, as I write this, I realize I made a mistake: that revision number
> is no longer the proper revision -- as there were a few fixes that went in
> after that. Please when you re-build, do a make clean before the new build
> of FedOne.
>> Second question: I've set up my server, opened the proper ports, and
>> connected using the run-console-client from a remote machine. However, I
>> haven't been able to test with other servers yet, and I'm curious about if
>> besides finding other servers to federate with, there are things that need
>> to be done in the configuration or build of the server, or if it will just
>> federate out of the current build without any special configuration
>> concerns.
> Simply login to wavesandbox, and add f...@domain.com to a wave (where
> domain is where FedOne is running) -- as long as you have the proper
> CA-validated certificates setup, it should all work. You should also be able
> to make a wave on your FedOne instance and add a participant on wavesandbox
> to that particular wave.
> Cheers,
> -Dan
>> Aldon
>> -----Original Message-----
>> *From:* wave-protocol@googlegroups.com [mailto:
>> wave-protocol@googlegroups.com]*On Behalf Of *Dan Peterson
>> *Sent:* Monday, November 02, 2009 1:18 PM
>> *To:* wave-protocol
>> *Subject:* Google Wave Federation Protocol port open on WaveSandbox.com
>> and Other Updates
>> Hi everyone,
>> Just a little bit ago we opened the federation port for Google Wave's
>> developer instance, so we can all begin experimenting with federating waves
>> against WaveSandbox <http://wavesandbox.com/>.com<http://wavesandbox.com/>.
>> Since that is the developer preview instance, please keep in mind that it is
>> an experimental service, and it is likely that there will be unforeseen
>> glitches in the coming weeks. Please share your progress here in the
>> wave-protocol forum, so we can work through issues together.
>> Over the next several weeks we plan to add some important features to this
>> service:
>> - TLS for XMPP:
>> - The protocol itself specifies two distinct security mechanisms:
>> delta signing and XMPP over TLS. Delta signing is required to be able to
>> verify the authenticity of the source of the operations. TLS is an
>> additional layer of security to the XMPP protocol, but it can be a bit hairy
>> to configure. In order to encourage prototyping, TLS is not enabled on
>> WaveSandbox.com, but it will become required in the coming weeks. This gives
>> existing FedOne instances an opportunity to get signed certificates and
>> configure their XMPP servers properly.
>> - Reliable Delivery:
>> - For any communication mechanism it is important that there is a
>> contract for delivery of the message contents, and we are working on a
>> reliable delivery mechanism from WaveSandbox.com.
>> With that said, to get started federating with WaveSandbox.com, you
>> should visit the wave-protocol project<http://code.google.com/p/wave-protocol/> and
>> review the installation instructions<http://code.google.com/p/wave-protocol/wiki/Installation>.
>> If you have previously installed and configured FedOne to talk to
>> other FedOne instances, you will need to upgrade to the latest revision
>> (revision 08b5eecb93) to properly interoperate with WaveSandbox.com. For
>> those of you building your own clients or servers, please take special care
>> to review the documentation that describes the errata<http://code.google.com/p/wave-protocol/wiki/DifferencesFromSpecificat...> between
>> the protocol specification and the current FedOne implementation between the
>> protocol specification and the current FedOne implementation, and
>> coincidentally, WaveSandbox.com.
>> As you are developing, please keep in mind we welcome contributions to the
>> growing open source reference implementation; please check out this guide
>> on submitting open source code<http://code.google.com/p/wave-protocol/wiki/SubmittingCode>
>> .
>> On the specification front, the Google Wave Conversation Model draft
>> specification has been revised and updated to include the blip document
>> schema, which defines the representation of rich text necessary for proper
>> interoperation with WaveSandbox.com. That document is available here:
>> http://www.waveprotocol.org/draft-protocol-specs/wave-conversation-model
>> The updated specifications and FedOne code introduce new changes to the
>> wave model, but they aren't the last; we expect more changes to come as we
>> iterate with you on the implementation and learn from these early
>> experiments in federation. Once the specifications and reference code have
>> converged and become reasonably stable we will begin to federate
>> wave.google.com, until then we have a lot of work to do. Looking forward
>> to hearing your feedback.
> * Reliable Delivery: > o For any communication mechanism it is important that there > is a contract for delivery of the message contents, and we > are working on a reliable delivery mechanism > from WaveSandbox.com.
What is meant by "reliable delivery"? What are your requirements for a reliable delivery mechanism? I ask because the broader XMPP developer community has put a lot of thought into this problem, and depending on your needs a solution might already exist. Let's not reinvent the wheel if we don't need to. :)
> On Mon, 2009-11-02 at 21:45 +0100, Ingo Vietense wrote:
>> Testing federation but i get a 404 from wavesandbox.com:
>> INFO | jvm 1 | 2009/11/02 21:39:33 | Nov 2, 2009 9:39:32 PM >> org.waveprotocol.wave.examples.fedone.federation.xmpp.WaveXmppComponent processPacket >> INFO | jvm 1 | 2009/11/02 21:39:33 | INFO: received XMPP packet: >> INFO | jvm 1 | 2009/11/02 21:39:33 | >> INFO | jvm 1 | 2009/11/02 21:39:33 |<iq type="error" id="9728-3" >> to="wave.devylon.com" from="wavesandbox.com"> >> INFO | jvm 1 | 2009/11/02 21:39:33 |<query >> xmlns="http://jabber.org/protocol/disco#items"/> >> INFO | jvm 1 | 2009/11/02 21:39:33 |<error code="404" >> type="cancel"> >> INFO | jvm 1 | 2009/11/02 21:39:33 |<remote-server-not-found >> xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/> >> INFO | jvm 1 | 2009/11/02 21:39:33 |</error> >> INFO | jvm 1 | 2009/11/02 21:39:33 |</iq> >> INFO | jvm 1 | 2009/11/02 21:39:33 | Nov 2, 2009 9:39:33 PM >> org.waveprotocol.wave.examples.fedone.federation.xmpp.WaveXmppComponent processPacket >> INFO | jvm 1 | 2009/11/02 21:39:33 | INFO: received XMPP packet: >> INFO | jvm 1 | 2009/11/02 21:39:33 | >> INFO | jvm 1 | 2009/11/02 21:39:33 |<iq type="error" id="4449-5" >> to="wave.devylon.com" from="wavesandbox.com"> >> INFO | jvm 1 | 2009/11/02 21:39:33 |<query >> xmlns="http://jabber.org/protocol/disco#items"/> >> INFO | jvm 1 | 2009/11/02 21:39:33 |<error code="404" >> type="cancel"> >> INFO | jvm 1 | 2009/11/02 21:39:33 |<remote-server-not-found >> xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/> >> INFO | jvm 1 | 2009/11/02 21:39:33 |</error> >> INFO | jvm 1 | 2009/11/02 21:39:33 |</iq>
> Hi Ingo,
> > From what I understand, the initial 404 is to be expected, however the > latest FedOne code does a graceful failover to ping wave.wavesandbox.com > after a certain amount of time.
First off well done to everyone concerned, I know how much work you guys have been putting into this so congrats.
Now to throw my own spanner into the works. I've got the latest HEAD FedOne up and running and am utilising a cert from startcom with a private key I generated myself. While I can recieve from wavesandbox (yay for character by character and sub blips!) I can't actually send. When I do try and submit an operation I get something like the following:
On Mon, 2009-11-02 at 23:57 +0100, Ingo Vietense wrote: > i pulled the current sources from the repository and recompiled everything. > now my log file looks like this:
<snip>
I've noticed that it does take a little while to get that initial response from wavesandbox.
> either in the wavesandbox gui i can see the wave, nor when i create a > wave at the wavesandbox.com and add the user to my fedone server.
> maybe there is an issue with my certificate ? i had fedone running a > while ago, so i think my DNS records should be okay.
On Tue, 2009-11-03 at 00:42 +0100, Ingo Vietense wrote: > I generated a cert at startcom. maybe there is an issue with my DNS ? > when i dig it i get no result:
Hrmm, I changed my server to ping devylon.com and it seems to have gotten a response. -- James Purser Collaborynth http://collaborynth.com.au Mob: +61 406 576 553 Skype: purserj1977 Twitter: http://twitter.com/purserj
hmmm... this is the openfire logfile, when i try to add my wavesandbox account to a wave within the console client:
2009.11.03 01:12:28 OutgoingSessionPromise: Error sending packet to remote server: <iq type="get" id="317-3" to="wavesandbox.com" from="wave.devylon.com"> <query xmlns="http://jabber.org/protocol/disco#items"/> </iq> java.lang.Exception: Failed to create connection to remote server at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.se ndPacket(OutgoingSessionPromise.java:252) at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.ru n(OutgoingSessionPromise.java:216) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.j ava:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java: 908) at java.lang.Thread.run(Thread.java:619) 2009.11.03 01:12:28 3591633 (01/05/00) - Connection #420 tested: OK 2009.11.03 01:12:28 3591634 (01/05/00) - Connection #420 tested: OK 2009.11.03 01:12:28 LocalOutgoingServerSession: OS - Trying to connect to wave.wavesandbox.com:5269(DNS lookup: xmpp-server2.l.google.com:5268) 2009.11.03 01:12:28 LocalOutgoingServerSession: OS - Plain connection to wave.wavesandbox.com:5269 successful 2009.11.03 01:12:28 LocalOutgoingServerSession: OS - About to try connecting using server dialback XMPP 1.0 with: wave.wavesandbox.com 2009.11.03 01:12:28 ServerDialback: OS - Sent dialback key to host: wave.wavesandbox.com id: 8B6700EE85E49604 from domain: wave.devylon.com 2009.11.03 01:12:29 Connect Socket[addr=/209.85.162.129,port=36052,localport=5269] 2009.11.03 01:12:29 Error creating session java.io.EOFException: input contained no data at org.xmlpull.mxp1.MXParser.fillBuf(MXParser.java:3003) at org.xmlpull.mxp1.MXParser.more(MXParser.java:3046) at org.xmlpull.mxp1.MXParser.parseProlog(MXParser.java:1410) at org.jivesoftware.openfire.net.MXParser.nextImpl(MXParser.java:332) at org.xmlpull.mxp1.MXParser.next(MXParser.java:1093) at org.jivesoftware.openfire.net.SocketReader.createSession(SocketReader.java: 364) at org.jivesoftware.openfire.net.BlockingReadingMode.run(BlockingReadingMode.j ava:54) at org.jivesoftware.openfire.net.SocketReader.run(SocketReader.java:120) at java.lang.Thread.run(Thread.java:619) 2009.11.03 01:12:29 Connection closed before session established Socket[addr=/209.85.162.129,port=36052,localport=5269] 2009.11.03 01:12:29 Connect Socket[addr=/209.85.162.129,port=36055,localport=5269] 2009.11.03 01:12:29 ServerDialback: RS - Received dialback key from host: gmail.com to: wave.devylon.com 2009.11.03 01:12:29 3591634 (01/05/00) - Connection #416 tested: OK 2009.11.03 01:12:29 3591635 (01/05/00) - Connection #416 tested: OK 2009.11.03 01:12:29 ServerDialback: RS - Trying to connect to Authoritative Server: gmail.com:5269(DNS lookup: xmpp-server2.l.google.com:5269) 2009.11.03 01:12:29 ServerDialback: RS - Connection to AS: gmail.com:5269 successful 2009.11.03 01:12:29 ServerDialback: RS - Asking AS to verify dialback key for idbe5f0df3 2009.11.03 01:12:29 ServerDialback: RS - Key was VERIFIED by the Authoritative Server for: gmail.com 2009.11.03 01:12:29 ServerDialback: RS - Closing connection to Authoritative Server: gmail.com 2009.11.03 01:12:29 ServerDialback: RS - Sending key verification result to OS: gmail.com 2009.11.03 01:12:29 ServerDialback: RS - Received dialback key from host: wave.wavesandbox.com to: wave.devylon.com 2009.11.03 01:12:29 ServerDialback: RS - Trying to connect to Authoritative Server: wave.wavesandbox.com:5268(DNS lookup: xmpp-server2.l.google.com:5268) 2009.11.03 01:12:29 ServerDialback: RS - Connection to AS: wave.wavesandbox.com:5268 successful 2009.11.03 01:12:30 ServerDialback: RS - Asking AS to verify dialback key for idbe5f0df3 2009.11.03 01:12:30 ServerDialback: RS - Key was VERIFIED by the Authoritative Server for: wave.wavesandbox.com 2009.11.03 01:12:30 ServerDialback: RS - Closing connection to Authoritative Server: wave.wavesandbox.com 2009.11.03 01:12:30 ServerDialback: RS - Sending key verification result to OS: wave.wavesandbox.com 2009.11.03 01:12:30 ServerDialback: AS - Verifying key for host: wave.wavesandbox.com id: 8B6700EE85E49604 2009.11.03 01:12:30 ServerDialback: AS - Key was: VALID for host: wave.wavesandbox.com id: 8B6700EE85E49604 2009.11.03 01:12:30 ServerDialback: OS - Validation GRANTED from: wave.wavesandbox.com id: 8B6700EE85E49604 for domain: wave.devylon.com 2009.11.03 01:12:30 LocalOutgoingServerSession: OS - SERVER DIALBACK XMPP 1.0 with wave.wavesandbox.com was successful
I'm seeing a lot of failing certificate verification in the logs, which
could be the cause of failed submits and updates to wavesandbox. Make sure
that signer verification is turned on on FedOne, i.e.
WAVESERVER_DISABLE_SIGNER_VERIFICATION=false in run-config.sh. If FedOne
doesn't start due to certificates, then that is the problem. If it does
start, then it's something else -- please keep reporting problems. Try to
include the wave id of any troublesome waves.
I'll submit a change later in the day to make this the default, but for now
keep it in mind.
-- Ben
On Tue, Nov 3, 2009 at 11:17 AM, Ingo Vietense <ingo.viete...@gmail.com>wrote:
> hmmm... this is the openfire logfile, when i try to add my wavesandbox
> account to a wave within
> the console client:
> 2009.11.03 01:12:28 OutgoingSessionPromise: Error sending packet to
> remote server:
> <iq type="get" id="317-3" to="wavesandbox.com" from="wave.devylon.com">
> <query xmlns="http://jabber.org/protocol/disco#items"/>
> </iq>
> java.lang.Exception: Failed to create connection to remote server
> at
> org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.se ndPacket(OutgoingSessionPromise.java:252)
> at
> org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.ru n(OutgoingSessionPromise.java:216)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.j ava:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java: 908)
> at java.lang.Thread.run(Thread.java:619)
> 2009.11.03 01:12:28 3591633 (01/05/00) - Connection #420 tested: OK
> 2009.11.03 01:12:28 3591634 (01/05/00) - Connection #420 tested: OK
> 2009.11.03 01:12:28 LocalOutgoingServerSession: OS - Trying to connect
> to wave.wavesandbox.com:5269(DNS lookup: xmpp-server2.l.google.com:5268)
> 2009.11.03 01:12:28 LocalOutgoingServerSession: OS - Plain connection to
> wave.wavesandbox.com:5269 successful
> 2009.11.03 01:12:28 LocalOutgoingServerSession: OS - About to try
> connecting using server dialback XMPP 1.0 with: wave.wavesandbox.com
> 2009.11.03 01:12:28 ServerDialback: OS - Sent dialback key to host:
> wave.wavesandbox.com id: 8B6700EE85E49604 from domain: wave.devylon.com
> 2009.11.03 01:12:29 Connect
> Socket[addr=/209.85.162.129,port=36052,localport=5269]
> 2009.11.03 01:12:29 Error creating session
> java.io.EOFException: input contained no data
> at org.xmlpull.mxp1.MXParser.fillBuf(MXParser.java:3003)
> at org.xmlpull.mxp1.MXParser.more(MXParser.java:3046)
> at org.xmlpull.mxp1.MXParser.parseProlog(MXParser.java:1410)
> at
> org.jivesoftware.openfire.net.MXParser.nextImpl(MXParser.java:332)
> at org.xmlpull.mxp1.MXParser.next(MXParser.java:1093)
> at
> org.jivesoftware.openfire.net.SocketReader.createSession(SocketReader.java: 364)
> at
> org.jivesoftware.openfire.net.BlockingReadingMode.run(BlockingReadingMode.j ava:54)
> at
> org.jivesoftware.openfire.net.SocketReader.run(SocketReader.java:120)
> at java.lang.Thread.run(Thread.java:619)
> 2009.11.03 01:12:29 Connection closed before session established
> Socket[addr=/209.85.162.129,port=36052,localport=5269]
> 2009.11.03 01:12:29 Connect
> Socket[addr=/209.85.162.129,port=36055,localport=5269]
> 2009.11.03 01:12:29 ServerDialback: RS - Received dialback key from
> host: gmail.com to: wave.devylon.com
> 2009.11.03 01:12:29 3591634 (01/05/00) - Connection #416 tested: OK
> 2009.11.03 01:12:29 3591635 (01/05/00) - Connection #416 tested: OK
> 2009.11.03 01:12:29 ServerDialback: RS - Trying to connect to
> Authoritative Server: gmail.com:5269(DNS lookup:
> xmpp-server2.l.google.com:5269)
> 2009.11.03 01:12:29 ServerDialback: RS - Connection to AS:
> gmail.com:5269 successful
> 2009.11.03 01:12:29 ServerDialback: RS - Asking AS to verify dialback
> key for idbe5f0df3
> 2009.11.03 01:12:29 ServerDialback: RS - Key was VERIFIED by the
> Authoritative Server for: gmail.com
> 2009.11.03 01:12:29 ServerDialback: RS - Closing connection to
> Authoritative Server: gmail.com
> 2009.11.03 01:12:29 ServerDialback: RS - Sending key verification result
> to OS: gmail.com
> 2009.11.03 01:12:29 ServerDialback: RS - Received dialback key from
> host: wave.wavesandbox.com to: wave.devylon.com
> 2009.11.03 01:12:29 ServerDialback: RS - Trying to connect to
> Authoritative Server: wave.wavesandbox.com:5268(DNS lookup:
> xmpp-server2.l.google.com:5268)
> 2009.11.03 01:12:29 ServerDialback: RS - Connection to AS:
> wave.wavesandbox.com:5268 successful
> 2009.11.03 01:12:30 ServerDialback: RS - Asking AS to verify dialback
> key for idbe5f0df3
> 2009.11.03 01:12:30 ServerDialback: RS - Key was VERIFIED by the
> Authoritative Server for: wave.wavesandbox.com
> 2009.11.03 01:12:30 ServerDialback: RS - Closing connection to
> Authoritative Server: wave.wavesandbox.com
> 2009.11.03 01:12:30 ServerDialback: RS - Sending key verification result
> to OS: wave.wavesandbox.com
> 2009.11.03 01:12:30 ServerDialback: AS - Verifying key for host:
> wave.wavesandbox.com id: 8B6700EE85E49604
> 2009.11.03 01:12:30 ServerDialback: AS - Key was: VALID for host:
> wave.wavesandbox.com id: 8B6700EE85E49604
> 2009.11.03 01:12:30 ServerDialback: OS - Validation GRANTED from:
> wave.wavesandbox.com id: 8B6700EE85E49604 for domain: wave.devylon.com
> 2009.11.03 01:12:30 LocalOutgoingServerSession: OS - SERVER DIALBACK
> XMPP 1.0 with wave.wavesandbox.com was successful
> Am 03.11.09 00:50, schrieb James Purser:
> > On Tue, 2009-11-03 at 00:42 +0100, Ingo Vietense wrote:
> >> I generated a cert at startcom. maybe there is an issue with my DNS ?
> >> when i dig it i get no result:
On Tue, 2009-11-03 at 12:15 +1100, Ben Kalman wrote: > I'm seeing a lot of failing certificate verification in the logs, > which could be the cause of failed submits and updates to wavesandbox. > Make sure that signer verification is turned on on FedOne, i.e. > WAVESERVER_DISABLE_SIGNER_VERIFICATION=false in run-config.sh. If > FedOne doesn't start due to certificates, then that is the problem. > If it does start, then it's something else -- please keep reporting > problems. Try to include the wave id of any troublesome waves.
> I'll submit a change later in the day to make this the default, but > for now keep it in mind.
> -- Ben
Hi Ben,
I've managed to fix my cert issue (well FedOne is starting without complaining now), it helps if you use the right intermediate cert with the right cert.
Anyway, I'm still timing out when trying to send from my FedOne client to wavesandbox.com. Below is the sort of packets I'm sending out and not getting a response to:
On Tue, 2009-11-03 at 13:41 +1100, Sam Thorogood wrote: > Explain - how are you going now, James?
Sorry, what I meant to say was that I've sorted out my certs issues. The problem was my own mistake (I'd manage to try and validate a startssl cert with a cacert intermediate cert). Now that part is fixed and I can start the server without issue and the certs appear to be being transferred back and forth.
However I'm still experiencing hangs when I try and reply to a wavesandbox.com wave. The logs indicate that an iq packet has been sent but there doesn't seem to be any response from wavesandbox.com -- James Purser Collaborynth http://collaborynth.com.au Mob: +61 406 576 553 Skype: purserj1977 Twitter: http://twitter.com/purserj
On Mon, Nov 2, 2009 at 9:53 PM, James Purser <jamesrpur...@gmail.com> wrote:
> On Tue, 2009-11-03 at 13:41 +1100, Sam Thorogood wrote:
> > Explain - how are you going now, James?
> Sorry, what I meant to say was that I've sorted out my certs issues. The
> problem was my own mistake (I'd manage to try and validate a startssl
> cert with a cacert intermediate cert). Now that part is fixed and I can
> start the server without issue and the certs appear to be being
> transferred back and forth.
> However I'm still experiencing hangs when I try and reply to a
> wavesandbox.com wave. The logs indicate that an iq packet has been sent
> but there doesn't seem to be any response from wavesandbox.com
I'm experiencing the exact same thing with startssl certs. We are working on
the
issue and will hopefully have a way to test if certs are going to work
against
wavesandbox.com.
On Tue, Nov 3, 2009 at 13:53, James Purser <jamesrpur...@gmail.com> wrote:
> On Tue, 2009-11-03 at 13:41 +1100, Sam Thorogood wrote:
>> Explain - how are you going now, James?
> Sorry, what I meant to say was that I've sorted out my certs issues. The
> problem was my own mistake (I'd manage to try and validate a startssl
> cert with a cacert intermediate cert). Now that part is fixed and I can
> start the server without issue and the certs appear to be being
> transferred back and forth.
> However I'm still experiencing hangs when I try and reply to a
> wavesandbox.com wave. The logs indicate that an iq packet has been sent
> but there doesn't seem to be any response from wavesandbox.com
> --
> James Purser
> Collaborynth
> http://collaborynth.com.au > Mob: +61 406 576 553
> Skype: purserj1977
> Twitter: http://twitter.com/purserj
For anyone who may be interested, I've written an article describing
my thoughts, from the perspective of a Drupal developer, about this
announcement of the opening of the federation port at WaveSandBox at
http://sites.google.com/site/federationprototypeserver/.
Ciao for now,
Kipp
On Nov 2, 1:18 pm, Dan Peterson <dpeter...@google.com> wrote:
> Just a little bit ago we opened the federation port for Google Wave's
> developer instance, so we can all begin experimenting with federating waves
> against WaveSandbox <http://wavesandbox.com/>.com <http://wavesandbox.com/>.
> Since that is the developer preview instance, please keep in mind that it is
> an experimental service, and it is likely that there will be unforeseen
> glitches in the coming weeks. Please share your progress here in the
> wave-protocol forum, so we can work through issues together.
> Over the next several weeks we plan to add some important features to this
> service:
> - TLS for XMPP:
> - The protocol itself specifies two distinct security mechanisms:
> delta signing and XMPP over TLS. Delta signing is required to be able to
> verify the authenticity of the source of the operations. TLS is an
> additional layer of security to the XMPP protocol, but it can be
> a bit hairy
> to configure. In order to encourage prototyping, TLS is not enabled on
> WaveSandbox.com, but it will become required in the coming
> weeks. This gives
> existing FedOne instances an opportunity to get signed certificates and
> configure their XMPP servers properly.
> - Reliable Delivery:
> - For any communication mechanism it is important that there is a
> contract for delivery of the message contents, and we are working on a
> reliable delivery mechanism from WaveSandbox.com.
> With that said, to get started federating with WaveSandbox.com, you should
> visit the wave-protocol project <http://code.google.com/p/wave-protocol/> and
> review the installation
> instructions<http://code.google.com/p/wave-protocol/wiki/Installation>.
> If you have previously installed and configured FedOne to talk to
> other FedOne instances, you will need to upgrade to the latest revision
> (revision 08b5eecb93) to properly interoperate with WaveSandbox.com. For
> those of you building your own clients or servers, please take special care
> to review the documentation that describes the
> errata<http://code.google.com/p/wave-protocol/wiki/DifferencesFromSpecificat...>
> between
> the protocol specification and the current FedOne implementation between the
> protocol specification and the current FedOne implementation, and
> coincidentally, WaveSandbox.com.
> As you are developing, please keep in mind we welcome contributions to the
> growing open source reference implementation; please check out this guide
> on submitting open source
> code<http://code.google.com/p/wave-protocol/wiki/SubmittingCode>
> .
> On the specification front, the Google Wave Conversation Model draft
> specification has been revised and updated to include the blip document
> schema, which defines the representation of rich text necessary for proper
> interoperation with WaveSandbox.com. That document is available here:http://www.waveprotocol.org/draft-protocol-specs/wave-conversation-model
> The updated specifications and FedOne code introduce new changes to the wave
> model, but they aren't the last; we expect more changes to come as we
> iterate with you on the implementation and learn from these early
> experiments in federation. Once the specifications and reference code have
> converged and become reasonably stable we will begin to federate
> wave.google.com, until then we have a lot of work to do. Looking forward to
> hearing your feedback.
As a quick response, the blog posts I've been writing and posting on
http://www.orient-lodge.com are all in Drupal
I'm using this server for hosting quite a few Drupal sites, as well as Elgg,
Joomla, Laconi.ca, probably wordpress and who knows what else.
It is the same site that I'm running my Openfire XMPP server and the Fedone
server.
Setting up FedOne on a server running Drupal is really no different than on
any other server.
I should also note that I'm running on a VPS server. Setting up FedOne on a
shared host probably just isn't possible, and would probably violate ToS for
most shared hosting services. I sure wouldn't want to try.
I should also note that laconi.ca is written in PHP and makes extensive use
of XMPP. I'm pretty sure it uses XMPPHP. I hope to do some
laconi.ca/FedOne testing when my FedOne instance is a little more stable.
As to connecting all of this to Drupal, my thoughts are that Drupal
developers should be looking more at Google Gadgets than at Federated
servers. In particular, I think Drupal developers should be paying
attention to Shindig and the Drupal Shindig shim as a means of working with
gadgets, but that is just my thinking at this point.
Has anyone on this list done anything interesting with Shindig, Gadgets,
Drupal, or some combination of the three?
[mailto:wave-protocol@googlegroups.com]On Behalf Of Kipp
Sent: Tuesday, November 03, 2009 7:33 PM
To: Wave Protocol
Subject: Re: Google Wave Federation Protocol port open on
WaveSandbox.com and Other Updates
For anyone who may be interested, I've written an article describing
my thoughts, from the perspective of a Drupal developer, about this
announcement of the opening of the federation port at WaveSandBox at
http://sites.google.com/site/federationprototypeserver/.
Ciao for now,
Kipp
On Nov 2, 1:18 pm, Dan Peterson <dpeter...@google.com> wrote:
> Hi everyone,
> Just a little bit ago we opened the federation port for Google Wave's
> developer instance, so we can all begin experimenting with federating
waves
> against WaveSandbox <http://wavesandbox.com/>.com
<http://wavesandbox.com/>.
> Since that is the developer preview instance, please keep in mind that it
is
> an experimental service, and it is likely that there will be unforeseen
> glitches in the coming weeks. Please share your progress here in the
> wave-protocol forum, so we can work through issues together.
> Over the next several weeks we plan to add some important features to this
> service:
> - TLS for XMPP:
> - The protocol itself specifies two distinct security mechanisms:
> delta signing and XMPP over TLS. Delta signing is required to be
able to
> verify the authenticity of the source of the operations. TLS is an
> additional layer of security to the XMPP protocol, but it can be
> a bit hairy
> to configure. In order to encourage prototyping, TLS is not enabled
on
> WaveSandbox.com, but it will become required in the coming
> weeks. This gives
> existing FedOne instances an opportunity to get signed certificates
and
> configure their XMPP servers properly.
> - Reliable Delivery:
> - For any communication mechanism it is important that there is a
> contract for delivery of the message contents, and we are working on
a
> reliable delivery mechanism from WaveSandbox.com.
> With that said, to get started federating with WaveSandbox.com, you should
> visit the wave-protocol project <http://code.google.com/p/wave-protocol/>
and
> review the installation
> instructions<http://code.google.com/p/wave-protocol/wiki/Installation>.
> If you have previously installed and configured FedOne to talk to
> other FedOne instances, you will need to upgrade to the latest revision
> (revision 08b5eecb93) to properly interoperate with WaveSandbox.com. For
> those of you building your own clients or servers, please take special
care
> to review the documentation that describes the
> As you are developing, please keep in mind we welcome contributions to the
> growing open source reference implementation; please check out this guide
> on submitting open source
> code<http://code.google.com/p/wave-protocol/wiki/SubmittingCode>
> .
> On the specification front, the Google Wave Conversation Model draft
> specification has been revised and updated to include the blip document
> schema, which defines the representation of rich text necessary for proper
> interoperation with WaveSandbox.com. That document is available
here:http://www.waveprotocol.org/draft-protocol-specs/wave-conversation-mode l
> The updated specifications and FedOne code introduce new changes to the
wave
> model, but they aren't the last; we expect more changes to come as we
> iterate with you on the implementation and learn from these early
> experiments in federation. Once the specifications and reference code have
> converged and become reasonably stable we will begin to federate
> wave.google.com, until then we have a lot of work to do. Looking forward
to
> hearing your feedback.
On Tue, Nov 3, 2009 at 7:59 AM, Peter Saint-Andre <stpe...@stpeter.im> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1
> On 11/2/09 11:18 AM, Dan Peterson wrote:
>> * Reliable Delivery: >> o For any communication mechanism it is important that there >> is a contract for delivery of the message contents, and we >> are working on a reliable delivery mechanism >> from WaveSandbox.com.
> What is meant by "reliable delivery"? What are your requirements for a > reliable delivery mechanism? I ask because the broader XMPP developer > community has put a lot of thought into this problem, and depending on > your needs a solution might already exist. Let's not reinvent the wheel > if we don't need to. :)
> Peter
Hi Peter,
We're still working through some of the finer points on "reliable delivery", we're also hoping to incorporate some form of flow control. We have yet to write a full spec of how we envision this mechanism to work, so if you allow be to be brief, we expect the requirements for "reliable delivery" to be: - short term retransmission and acknowledgement of all messages (this can be done using regular XMPP mechanisms). - selectively dropping non-essential messages queued for retransmission if there are any non-trivial transmission delays (e.g. delta updates, which can be recovered by a receiver using getHistory on receipt of a commit notification). - keeping retransmission efficient by only sending of essential messages over a significant amount of time (e.g. days, weeks,.... months? if a wave provider has gone offline. The retransmission policy might be similar to what happens with SMTP (*)). Essential messages would include the last commit notification for all wavelets on which a provider has users.
(*) One might possibly add an active mechanism on the receiver's part to query for new waves, however there are a few issues with this. e.g after being down for a long while, receivers can't know the complete set of servers to contact for waves without some central authority informing a provider which providers have waves for whom.
> As a quick response, the blog posts I've been writing and posting on
> http://www.orient-lodge.com are all in Drupal
> I'm using this server for hosting quite a few Drupal sites, as well as
> Elgg,
> Joomla, Laconi.ca, probably wordpress and who knows what else.
> It is the same site that I'm running my Openfire XMPP server and the Fedone
> server.
> Setting up FedOne on a server running Drupal is really no different than on
> any other server.
> I should also note that I'm running on a VPS server. Setting up FedOne on
> a
> shared host probably just isn't possible, and would probably violate ToS
> for
> most shared hosting services. I sure wouldn't want to try.
> I should also note that laconi.ca is written in PHP and makes extensive
> use
> of XMPP. I'm pretty sure it uses XMPPHP. I hope to do some
> laconi.ca/FedOne testing when my FedOne instance is a little more stable.
> As to connecting all of this to Drupal, my thoughts are that Drupal
> developers should be looking more at Google Gadgets than at Federated
> servers. In particular, I think Drupal developers should be paying
> attention to Shindig and the Drupal Shindig shim as a means of working with
> gadgets, but that is just my thinking at this point.
> Has anyone on this list done anything interesting with Shindig, Gadgets,
> Drupal, or some combination of the three?
> Enough for now.
> Aldon
> -----Original Message-----
> From: wave-protocol@googlegroups.com
> [mailto:wave-protocol@googlegroups.com]On Behalf Of Kipp
> Sent: Tuesday, November 03, 2009 7:33 PM
> To: Wave Protocol
> Subject: Re: Google Wave Federation Protocol port open on
> WaveSandbox.com and Other Updates
> For anyone who may be interested, I've written an article describing
> my thoughts, from the perspective of a Drupal developer, about this
> announcement of the opening of the federation port at WaveSandBox at
> http://sites.google.com/site/federationprototypeserver/.
> Ciao for now,
> Kipp
> On Nov 2, 1:18 pm, Dan Peterson <dpeter...@google.com> wrote:
> > Hi everyone,
> > Just a little bit ago we opened the federation port for Google Wave's
> > developer instance, so we can all begin experimenting with federating
> waves
> > against WaveSandbox <http://wavesandbox.com/>.com
> <http://wavesandbox.com/>.
> > Since that is the developer preview instance, please keep in mind that it
> is
> > an experimental service, and it is likely that there will be unforeseen
> > glitches in the coming weeks. Please share your progress here in the
> > wave-protocol forum, so we can work through issues together.
> > Over the next several weeks we plan to add some important features to
> this
> > service:
> > - TLS for XMPP:
> > - The protocol itself specifies two distinct security mechanisms:
> > delta signing and XMPP over TLS. Delta signing is required to be
> able to
> > verify the authenticity of the source of the operations. TLS is an
> > additional layer of security to the XMPP protocol, but it can be
> > a bit hairy
> > to configure. In order to encourage prototyping, TLS is not enabled
> on
> > WaveSandbox.com, but it will become required in the coming
> > weeks. This gives
> > existing FedOne instances an opportunity to get signed certificates
> and
> > configure their XMPP servers properly.
> > - Reliable Delivery:
> > - For any communication mechanism it is important that there is a
> > contract for delivery of the message contents, and we are working
> on
> a
> > reliable delivery mechanism from WaveSandbox.com.
> > With that said, to get started federating with WaveSandbox.com, you
> should
> > visit the wave-protocol project <http://code.google.com/p/wave-protocol/
> and
> > review the installation
> > instructions<http://code.google.com/p/wave-protocol/wiki/Installation>.
> > If you have previously installed and configured FedOne to talk to
> > other FedOne instances, you will need to upgrade to the latest revision
> > (revision 08b5eecb93) to properly interoperate with WaveSandbox.com. For
> > those of you building your own clients or servers, please take special
> care
> > to review the documentation that describes the
> errata<
> http://code.google.com/p/wave-protocol/wiki/DifferencesFromSpecificat > ...>
> > between
> > the protocol specification and the current FedOne implementation between
> the
> > protocol specification and the current FedOne implementation, and
> > coincidentally, WaveSandbox.com.
> > As you are developing, please keep in mind we welcome contributions to
> the
> > growing open source reference implementation; please check out this guide
> > on submitting open source
> > code<http://code.google.com/p/wave-protocol/wiki/SubmittingCode>
> > .
> > On the specification front, the Google Wave Conversation Model draft
> > specification has been revised and updated to include the blip document
> > schema, which defines the representation of rich text necessary for
> proper
> > interoperation with WaveSandbox.com. That document is available
> here:
> http://www.waveprotocol.org/draft-protocol-specs/wave-conversation-mode > l
> > The updated specifications and FedOne code introduce new changes to the
> wave
> > model, but they aren't the last; we expect more changes to come as we
> > iterate with you on the implementation and learn from these early
> > experiments in federation. Once the specifications and reference code
> have
> > converged and become reasonably stable we will begin to federate
> > wave.google.com, until then we have a lot of work to do. Looking forward
> to
> > hearing your feedback.
