[DISCUSS] future directions

[Edward Capriolo <ed...@gmail.com>]

We currently have almost 10 open tickets for features / improvements to
gossip, many are slated for the next release and we are on our way to be
ahead of schedule with that.

I wanted to pick everyone's brain as to where we should aim for.

I think some larger general directions are below:

1) SWIM. https://www.cs.cornell.edu/~asdas/research/dsn02-swim.pdf

This is a fairly large undertaking in terms of codifying the protocol and
keeping the project elegant with two Failure Detectors

2) HTTP as transport

Having two transports in the codebase is simple. I think this will go well
 HTTP clients do all the session/persistence. Transplanting Gossip to live
in a webapp wont be too bad but it might involve re-orging the project a
bit into a multi-module maven project. I see a lot of upside here

3) Signed messages (https://issues.apache.org/jira/browse/GOSSIP-47)

While I am not a super expert in keystores and such this strikes me as
interesting idea. Mostly because it allows peers to share info but also be
able to sign/verify/encrypt info as it moves between peers. I have never
seen something quite like this so I think it is novel.

4) Recipes

Building things like Ephemeral Nodes or Leader Election seem to be a good
fit. Gossip should not be a database so this is a hard line to draw. This
will take some research and expertise to implement correctly.

5) Second implementation

Originally I planned to build out a second implementation in c, node, or
python. This seems less appealing to me at the moment, but if Gossip Java
gets too large/complex we will likely miss out window to do this.

6) something massive to spin up N instances in amazon and do testing

This is something that needs to happen, maybe in two parts.

7) Other ideas? Let them fly.

Thanks,
Edward

Re: [DISCUSS] future directions

[Edward Capriolo <ed...@gmail.com>]

On Fri, Feb 3, 2017 at 1:15 PM, Edward Capriolo <ed...@gmail.com>
wrote:

>
> On Fri, Feb 3, 2017 at 1:13 PM, Dorian Ellerbe <do...@gmail.com>
> wrote:
>
>> Great ideas!
>>
>> 1) Regarding SWIM: Looks interesting, but I want to understand/research
>> more.
>>
>> 2) +1 for HTTP. Anything to appeal to a larger audience of users and
>> committers is good, especially if the dev overhead is relatively low.
>>
>> 5) Same idea as #2 above; though this will obviously require a larger
>> effort. Maybe a functional implementation?
>>
>> 6) I've been reading a lot about Docker Swarm. We can spin up N instances
>> of members and configure them in virtually (no pun) anyway we want. There
>> are some excellent use cases for it and this is certainly one of them.
>>
>> On Mon, Jan 30, 2017 at 2:21 PM Edward Capriolo <ed...@gmail.com>
>> wrote:
>>
>> > On Mon, Jan 30, 2017 at 1:03 PM, Sandeep More <mo...@gmail.com>
>> > wrote:
>> >
>> > > For #3 the problem is a digest is not easy. The reason is that hosts
>> > > communicate through each other. If there were three nodes A, B, and C,
>> > and
>> > > a message was sent from A -> B and then the message was sent from B
>> -> C.
>> > > Node B would be able to change the data and the digest. What I want
>> to do
>> > > is be able to ensure that the data is verified by A. This would be
>> > > something like a PGP email. I want to verify that the message is
>> > unaltered
>> > > and that it is from a specific sender.
>> > >
>> > > SRM: I see, that would be complicated verifying the sender. I was
>> > thinking
>> > > of just verifying the signature on the hashes. Assuming we have a
>> shared
>> > > secret amongst all the nodes verifying a signature would not be too
>> > > difficult. Verifying that the data comes from a specific node might be
>> > > tricky.
>> > >
>> > > "It would be really cool if one could choose a custom data (like a
>> > > String/Long value), I understand that this could be misused and
>> > > misinterpreted as datastorage so may be there can be stricter limits
>> on
>> > the
>> > > size of the custom payload. This might help Apps to integrate Gossip
>> > > better."
>> > >
>> > > I am unclear about what you are saying here. We can already gossip
>> > > arbitrary data between nodes.
>> > >
>> > > SRM: My bad, I missed this, thanks for pointing it out !
>> > >
>> > > https://github.com/apache/incubator-gossip/blob/master/
>> > > src/test/java/org/apache/gossip/DataTest.java
>> > >
>> > > Thanks,
>> > > Edward
>> > >
>> > > On Mon, Jan 30, 2017 at 12:45 PM, Edward Capriolo <
>> edlinuxguru@gmail.com
>> > >
>> > > wrote:
>> > >
>> > > > On Mon, Jan 30, 2017 at 9:13 AM, Sandeep More <
>> moresandeep@gmail.com>
>> > > > wrote:
>> > > >
>> > > > > This is exciting !
>> > > > >
>> > > > > #3, #2 and #1 especially look a great value add.
>> > > > >
>> > > > > On #3 I think signing the digest would be easier in short run,
>> > > encrypting
>> > > > > will mean involving complex keystore/truststore setup.
>> > > > >
>> > > > > May be you already covered this in Recipes or elsewhere but still
>> > > putting
>> > > > > it here:
>> > > > >
>> > > > > It would be really cool if one could choose a custom data (like a
>> > > > > String/Long value), I understand that this could be misused and
>> > > > > misinterpreted as datastorage so may be there can be stricter
>> limits
>> > on
>> > > > the
>> > > > > size of the custom payload. This might help Apps to integrate
>> Gossip
>> > > > > better.
>> > > > >
>> > > > > Just a thought !
>> > > > >
>> > > > > Best,
>> > > > > Sandeep
>> > > > >
>> > > > > On Sun, Jan 29, 2017 at 10:25 PM, Edward Capriolo <
>> > > edlinuxguru@gmail.com
>> > > > >
>> > > > > wrote:
>> > > > >
>> > > > > > We currently have almost 10 open tickets for features /
>> > improvements
>> > > to
>> > > > > > gossip, many are slated for the next release and we are on our
>> way
>> > to
>> > > > be
>> > > > > > ahead of schedule with that.
>> > > > > >
>> > > > > > I wanted to pick everyone's brain as to where we should aim for.
>> > > > > >
>> > > > > > I think some larger general directions are below:
>> > > > > >
>> > > > > > 1) SWIM. https://www.cs.cornell.edu/~as
>> das/research/dsn02-swim.pdf
>> > > > > >
>> > > > > > This is a fairly large undertaking in terms of codifying the
>> > protocol
>> > > > and
>> > > > > > keeping the project elegant with two Failure Detectors
>> > > > > >
>> > > > > > 2) HTTP as transport
>> > > > > >
>> > > > > > Having two transports in the codebase is simple. I think this
>> will
>> > go
>> > > > > well
>> > > > > >  HTTP clients do all the session/persistence. Transplanting
>> Gossip
>> > to
>> > > > > live
>> > > > > > in a webapp wont be too bad but it might involve re-orging the
>> > > project
>> > > > a
>> > > > > > bit into a multi-module maven project. I see a lot of upside
>> here
>> > > > > >
>> > > > > > 3) Signed messages (
>> > https://issues.apache.org/jira/browse/GOSSIP-47)
>> > > > > >
>> > > > > > While I am not a super expert in keystores and such this
>> strikes me
>> > > as
>> > > > > > interesting idea. Mostly because it allows peers to share info
>> but
>> > > also
>> > > > > be
>> > > > > > able to sign/verify/encrypt info as it moves between peers. I
>> have
>> > > > never
>> > > > > > seen something quite like this so I think it is novel.
>> > > > > >
>> > > > > > 4) Recipes
>> > > > > >
>> > > > > > Building things like Ephemeral Nodes or Leader Election seem to
>> be
>> > a
>> > > > good
>> > > > > > fit. Gossip should not be a database so this is a hard line to
>> > draw.
>> > > > This
>> > > > > > will take some research and expertise to implement correctly.
>> > > > > >
>> > > > > > 5) Second implementation
>> > > > > >
>> > > > > > Originally I planned to build out a second implementation in c,
>> > node,
>> > > > or
>> > > > > > python. This seems less appealing to me at the moment, but if
>> > Gossip
>> > > > Java
>> > > > > > gets too large/complex we will likely miss out window to do
>> this.
>> > > > > >
>> > > > > > 6) something massive to spin up N instances in amazon and do
>> > testing
>> > > > > >
>> > > > > > This is something that needs to happen, maybe in two parts.
>> > > > > >
>> > > > > > 7) Other ideas? Let them fly.
>> > > > > >
>> > > > > > Thanks,
>> > > > > > Edward
>> > > > > >
>> > > > >
>> > > >
>> > > > For #3 the problem is a digest is not easy. The reason is that hosts
>> > > > communicate through each other. If there were three nodes A, B, and
>> C,
>> > > and
>> > > > a message was sent from A -> B and then the message was sent from B
>> ->
>> > C.
>> > > > Node B would be able to change the data and the digest. What I want
>> to
>> > do
>> > > > is be able to ensure that the data is verified by A. This would be
>> > > > something like a PGP email. I want to verify that the message is
>> > > unaltered
>> > > > and that it is from a specific sender.
>> > > >
>> > > > "It would be really cool if one could choose a custom data (like a
>> > > > String/Long value), I understand that this could be misused and
>> > > > misinterpreted as datastorage so may be there can be stricter
>> limits on
>> > > the
>> > > > size of the custom payload. This might help Apps to integrate Gossip
>> > > > better."
>> > > >
>> > > > I am unclear about what you are saying here. We can already gossip
>> > > > arbitrary data between nodes.
>> > > >
>> > > > https://github.com/apache/incubator-gossip/blob/master/
>> > > > src/test/java/org/apache/gossip/DataTest.java
>> > > >
>> > > > Thanks,
>> > > > Edward
>> > > >
>> > >
>> >
>> > " Verifying that the data comes from a specific node might be tricky."
>> >
>> > For this feature to work the cluster nodes with either need one or more
>> Pre
>> > Shared Key or they would all have to agree on a (central) Certificate
>> > Authority that could grant and verify. I would not expect this to be the
>> > standard mode for most users, but I think it is fairly novel and would
>> be
>> > interesting to me.
>> >
>>
>
> For #6 there are likely a few apache projects products producing docker
> images. I am open to implementation here.
>

Update: I realized when I setup the time based release I said 3 months,
however I set the date as march 8th which was only two months in the
future. LOL anyway great way to trick yourself. I set up the version 0.1.3
in Jira and moved many of these topics into that version.

Re: [DISCUSS] future directions

[Edward Capriolo <ed...@gmail.com>]

On Fri, Feb 3, 2017 at 1:13 PM, Dorian Ellerbe <do...@gmail.com>
wrote:

> Great ideas!
>
> 1) Regarding SWIM: Looks interesting, but I want to understand/research
> more.
>
> 2) +1 for HTTP. Anything to appeal to a larger audience of users and
> committers is good, especially if the dev overhead is relatively low.
>
> 5) Same idea as #2 above; though this will obviously require a larger
> effort. Maybe a functional implementation?
>
> 6) I've been reading a lot about Docker Swarm. We can spin up N instances
> of members and configure them in virtually (no pun) anyway we want. There
> are some excellent use cases for it and this is certainly one of them.
>
> On Mon, Jan 30, 2017 at 2:21 PM Edward Capriolo <ed...@gmail.com>
> wrote:
>
> > On Mon, Jan 30, 2017 at 1:03 PM, Sandeep More <mo...@gmail.com>
> > wrote:
> >
> > > For #3 the problem is a digest is not easy. The reason is that hosts
> > > communicate through each other. If there were three nodes A, B, and C,
> > and
> > > a message was sent from A -> B and then the message was sent from B ->
> C.
> > > Node B would be able to change the data and the digest. What I want to
> do
> > > is be able to ensure that the data is verified by A. This would be
> > > something like a PGP email. I want to verify that the message is
> > unaltered
> > > and that it is from a specific sender.
> > >
> > > SRM: I see, that would be complicated verifying the sender. I was
> > thinking
> > > of just verifying the signature on the hashes. Assuming we have a
> shared
> > > secret amongst all the nodes verifying a signature would not be too
> > > difficult. Verifying that the data comes from a specific node might be
> > > tricky.
> > >
> > > "It would be really cool if one could choose a custom data (like a
> > > String/Long value), I understand that this could be misused and
> > > misinterpreted as datastorage so may be there can be stricter limits on
> > the
> > > size of the custom payload. This might help Apps to integrate Gossip
> > > better."
> > >
> > > I am unclear about what you are saying here. We can already gossip
> > > arbitrary data between nodes.
> > >
> > > SRM: My bad, I missed this, thanks for pointing it out !
> > >
> > > https://github.com/apache/incubator-gossip/blob/master/
> > > src/test/java/org/apache/gossip/DataTest.java
> > >
> > > Thanks,
> > > Edward
> > >
> > > On Mon, Jan 30, 2017 at 12:45 PM, Edward Capriolo <
> edlinuxguru@gmail.com
> > >
> > > wrote:
> > >
> > > > On Mon, Jan 30, 2017 at 9:13 AM, Sandeep More <moresandeep@gmail.com
> >
> > > > wrote:
> > > >
> > > > > This is exciting !
> > > > >
> > > > > #3, #2 and #1 especially look a great value add.
> > > > >
> > > > > On #3 I think signing the digest would be easier in short run,
> > > encrypting
> > > > > will mean involving complex keystore/truststore setup.
> > > > >
> > > > > May be you already covered this in Recipes or elsewhere but still
> > > putting
> > > > > it here:
> > > > >
> > > > > It would be really cool if one could choose a custom data (like a
> > > > > String/Long value), I understand that this could be misused and
> > > > > misinterpreted as datastorage so may be there can be stricter
> limits
> > on
> > > > the
> > > > > size of the custom payload. This might help Apps to integrate
> Gossip
> > > > > better.
> > > > >
> > > > > Just a thought !
> > > > >
> > > > > Best,
> > > > > Sandeep
> > > > >
> > > > > On Sun, Jan 29, 2017 at 10:25 PM, Edward Capriolo <
> > > edlinuxguru@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > > > We currently have almost 10 open tickets for features /
> > improvements
> > > to
> > > > > > gossip, many are slated for the next release and we are on our
> way
> > to
> > > > be
> > > > > > ahead of schedule with that.
> > > > > >
> > > > > > I wanted to pick everyone's brain as to where we should aim for.
> > > > > >
> > > > > > I think some larger general directions are below:
> > > > > >
> > > > > > 1) SWIM. https://www.cs.cornell.edu/~
> asdas/research/dsn02-swim.pdf
> > > > > >
> > > > > > This is a fairly large undertaking in terms of codifying the
> > protocol
> > > > and
> > > > > > keeping the project elegant with two Failure Detectors
> > > > > >
> > > > > > 2) HTTP as transport
> > > > > >
> > > > > > Having two transports in the codebase is simple. I think this
> will
> > go
> > > > > well
> > > > > >  HTTP clients do all the session/persistence. Transplanting
> Gossip
> > to
> > > > > live
> > > > > > in a webapp wont be too bad but it might involve re-orging the
> > > project
> > > > a
> > > > > > bit into a multi-module maven project. I see a lot of upside here
> > > > > >
> > > > > > 3) Signed messages (
> > https://issues.apache.org/jira/browse/GOSSIP-47)
> > > > > >
> > > > > > While I am not a super expert in keystores and such this strikes
> me
> > > as
> > > > > > interesting idea. Mostly because it allows peers to share info
> but
> > > also
> > > > > be
> > > > > > able to sign/verify/encrypt info as it moves between peers. I
> have
> > > > never
> > > > > > seen something quite like this so I think it is novel.
> > > > > >
> > > > > > 4) Recipes
> > > > > >
> > > > > > Building things like Ephemeral Nodes or Leader Election seem to
> be
> > a
> > > > good
> > > > > > fit. Gossip should not be a database so this is a hard line to
> > draw.
> > > > This
> > > > > > will take some research and expertise to implement correctly.
> > > > > >
> > > > > > 5) Second implementation
> > > > > >
> > > > > > Originally I planned to build out a second implementation in c,
> > node,
> > > > or
> > > > > > python. This seems less appealing to me at the moment, but if
> > Gossip
> > > > Java
> > > > > > gets too large/complex we will likely miss out window to do this.
> > > > > >
> > > > > > 6) something massive to spin up N instances in amazon and do
> > testing
> > > > > >
> > > > > > This is something that needs to happen, maybe in two parts.
> > > > > >
> > > > > > 7) Other ideas? Let them fly.
> > > > > >
> > > > > > Thanks,
> > > > > > Edward
> > > > > >
> > > > >
> > > >
> > > > For #3 the problem is a digest is not easy. The reason is that hosts
> > > > communicate through each other. If there were three nodes A, B, and
> C,
> > > and
> > > > a message was sent from A -> B and then the message was sent from B
> ->
> > C.
> > > > Node B would be able to change the data and the digest. What I want
> to
> > do
> > > > is be able to ensure that the data is verified by A. This would be
> > > > something like a PGP email. I want to verify that the message is
> > > unaltered
> > > > and that it is from a specific sender.
> > > >
> > > > "It would be really cool if one could choose a custom data (like a
> > > > String/Long value), I understand that this could be misused and
> > > > misinterpreted as datastorage so may be there can be stricter limits
> on
> > > the
> > > > size of the custom payload. This might help Apps to integrate Gossip
> > > > better."
> > > >
> > > > I am unclear about what you are saying here. We can already gossip
> > > > arbitrary data between nodes.
> > > >
> > > > https://github.com/apache/incubator-gossip/blob/master/
> > > > src/test/java/org/apache/gossip/DataTest.java
> > > >
> > > > Thanks,
> > > > Edward
> > > >
> > >
> >
> > " Verifying that the data comes from a specific node might be tricky."
> >
> > For this feature to work the cluster nodes with either need one or more
> Pre
> > Shared Key or they would all have to agree on a (central) Certificate
> > Authority that could grant and verify. I would not expect this to be the
> > standard mode for most users, but I think it is fairly novel and would be
> > interesting to me.
> >
>

For #6 there are likely a few apache projects products producing docker
images. I am open to implementation here.

Re: [DISCUSS] future directions

[Dorian Ellerbe <do...@gmail.com>]

Great ideas!

1) Regarding SWIM: Looks interesting, but I want to understand/research
more.

2) +1 for HTTP. Anything to appeal to a larger audience of users and
committers is good, especially if the dev overhead is relatively low.

5) Same idea as #2 above; though this will obviously require a larger
effort. Maybe a functional implementation?

6) I've been reading a lot about Docker Swarm. We can spin up N instances
of members and configure them in virtually (no pun) anyway we want. There
are some excellent use cases for it and this is certainly one of them.

On Mon, Jan 30, 2017 at 2:21 PM Edward Capriolo <ed...@gmail.com>
wrote:

> On Mon, Jan 30, 2017 at 1:03 PM, Sandeep More <mo...@gmail.com>
> wrote:
>
> > For #3 the problem is a digest is not easy. The reason is that hosts
> > communicate through each other. If there were three nodes A, B, and C,
> and
> > a message was sent from A -> B and then the message was sent from B -> C.
> > Node B would be able to change the data and the digest. What I want to do
> > is be able to ensure that the data is verified by A. This would be
> > something like a PGP email. I want to verify that the message is
> unaltered
> > and that it is from a specific sender.
> >
> > SRM: I see, that would be complicated verifying the sender. I was
> thinking
> > of just verifying the signature on the hashes. Assuming we have a shared
> > secret amongst all the nodes verifying a signature would not be too
> > difficult. Verifying that the data comes from a specific node might be
> > tricky.
> >
> > "It would be really cool if one could choose a custom data (like a
> > String/Long value), I understand that this could be misused and
> > misinterpreted as datastorage so may be there can be stricter limits on
> the
> > size of the custom payload. This might help Apps to integrate Gossip
> > better."
> >
> > I am unclear about what you are saying here. We can already gossip
> > arbitrary data between nodes.
> >
> > SRM: My bad, I missed this, thanks for pointing it out !
> >
> > https://github.com/apache/incubator-gossip/blob/master/
> > src/test/java/org/apache/gossip/DataTest.java
> >
> > Thanks,
> > Edward
> >
> > On Mon, Jan 30, 2017 at 12:45 PM, Edward Capriolo <edlinuxguru@gmail.com
> >
> > wrote:
> >
> > > On Mon, Jan 30, 2017 at 9:13 AM, Sandeep More <mo...@gmail.com>
> > > wrote:
> > >
> > > > This is exciting !
> > > >
> > > > #3, #2 and #1 especially look a great value add.
> > > >
> > > > On #3 I think signing the digest would be easier in short run,
> > encrypting
> > > > will mean involving complex keystore/truststore setup.
> > > >
> > > > May be you already covered this in Recipes or elsewhere but still
> > putting
> > > > it here:
> > > >
> > > > It would be really cool if one could choose a custom data (like a
> > > > String/Long value), I understand that this could be misused and
> > > > misinterpreted as datastorage so may be there can be stricter limits
> on
> > > the
> > > > size of the custom payload. This might help Apps to integrate Gossip
> > > > better.
> > > >
> > > > Just a thought !
> > > >
> > > > Best,
> > > > Sandeep
> > > >
> > > > On Sun, Jan 29, 2017 at 10:25 PM, Edward Capriolo <
> > edlinuxguru@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > We currently have almost 10 open tickets for features /
> improvements
> > to
> > > > > gossip, many are slated for the next release and we are on our way
> to
> > > be
> > > > > ahead of schedule with that.
> > > > >
> > > > > I wanted to pick everyone's brain as to where we should aim for.
> > > > >
> > > > > I think some larger general directions are below:
> > > > >
> > > > > 1) SWIM. https://www.cs.cornell.edu/~asdas/research/dsn02-swim.pdf
> > > > >
> > > > > This is a fairly large undertaking in terms of codifying the
> protocol
> > > and
> > > > > keeping the project elegant with two Failure Detectors
> > > > >
> > > > > 2) HTTP as transport
> > > > >
> > > > > Having two transports in the codebase is simple. I think this will
> go
> > > > well
> > > > >  HTTP clients do all the session/persistence. Transplanting Gossip
> to
> > > > live
> > > > > in a webapp wont be too bad but it might involve re-orging the
> > project
> > > a
> > > > > bit into a multi-module maven project. I see a lot of upside here
> > > > >
> > > > > 3) Signed messages (
> https://issues.apache.org/jira/browse/GOSSIP-47)
> > > > >
> > > > > While I am not a super expert in keystores and such this strikes me
> > as
> > > > > interesting idea. Mostly because it allows peers to share info but
> > also
> > > > be
> > > > > able to sign/verify/encrypt info as it moves between peers. I have
> > > never
> > > > > seen something quite like this so I think it is novel.
> > > > >
> > > > > 4) Recipes
> > > > >
> > > > > Building things like Ephemeral Nodes or Leader Election seem to be
> a
> > > good
> > > > > fit. Gossip should not be a database so this is a hard line to
> draw.
> > > This
> > > > > will take some research and expertise to implement correctly.
> > > > >
> > > > > 5) Second implementation
> > > > >
> > > > > Originally I planned to build out a second implementation in c,
> node,
> > > or
> > > > > python. This seems less appealing to me at the moment, but if
> Gossip
> > > Java
> > > > > gets too large/complex we will likely miss out window to do this.
> > > > >
> > > > > 6) something massive to spin up N instances in amazon and do
> testing
> > > > >
> > > > > This is something that needs to happen, maybe in two parts.
> > > > >
> > > > > 7) Other ideas? Let them fly.
> > > > >
> > > > > Thanks,
> > > > > Edward
> > > > >
> > > >
> > >
> > > For #3 the problem is a digest is not easy. The reason is that hosts
> > > communicate through each other. If there were three nodes A, B, and C,
> > and
> > > a message was sent from A -> B and then the message was sent from B ->
> C.
> > > Node B would be able to change the data and the digest. What I want to
> do
> > > is be able to ensure that the data is verified by A. This would be
> > > something like a PGP email. I want to verify that the message is
> > unaltered
> > > and that it is from a specific sender.
> > >
> > > "It would be really cool if one could choose a custom data (like a
> > > String/Long value), I understand that this could be misused and
> > > misinterpreted as datastorage so may be there can be stricter limits on
> > the
> > > size of the custom payload. This might help Apps to integrate Gossip
> > > better."
> > >
> > > I am unclear about what you are saying here. We can already gossip
> > > arbitrary data between nodes.
> > >
> > > https://github.com/apache/incubator-gossip/blob/master/
> > > src/test/java/org/apache/gossip/DataTest.java
> > >
> > > Thanks,
> > > Edward
> > >
> >
>
> " Verifying that the data comes from a specific node might be tricky."
>
> For this feature to work the cluster nodes with either need one or more Pre
> Shared Key or they would all have to agree on a (central) Certificate
> Authority that could grant and verify. I would not expect this to be the
> standard mode for most users, but I think it is fairly novel and would be
> interesting to me.
>

Re: [DISCUSS] future directions

[Edward Capriolo <ed...@gmail.com>]

On Mon, Jan 30, 2017 at 1:03 PM, Sandeep More <mo...@gmail.com> wrote:

> For #3 the problem is a digest is not easy. The reason is that hosts
> communicate through each other. If there were three nodes A, B, and C, and
> a message was sent from A -> B and then the message was sent from B -> C.
> Node B would be able to change the data and the digest. What I want to do
> is be able to ensure that the data is verified by A. This would be
> something like a PGP email. I want to verify that the message is unaltered
> and that it is from a specific sender.
>
> SRM: I see, that would be complicated verifying the sender. I was thinking
> of just verifying the signature on the hashes. Assuming we have a shared
> secret amongst all the nodes verifying a signature would not be too
> difficult. Verifying that the data comes from a specific node might be
> tricky.
>
> "It would be really cool if one could choose a custom data (like a
> String/Long value), I understand that this could be misused and
> misinterpreted as datastorage so may be there can be stricter limits on the
> size of the custom payload. This might help Apps to integrate Gossip
> better."
>
> I am unclear about what you are saying here. We can already gossip
> arbitrary data between nodes.
>
> SRM: My bad, I missed this, thanks for pointing it out !
>
> https://github.com/apache/incubator-gossip/blob/master/
> src/test/java/org/apache/gossip/DataTest.java
>
> Thanks,
> Edward
>
> On Mon, Jan 30, 2017 at 12:45 PM, Edward Capriolo <ed...@gmail.com>
> wrote:
>
> > On Mon, Jan 30, 2017 at 9:13 AM, Sandeep More <mo...@gmail.com>
> > wrote:
> >
> > > This is exciting !
> > >
> > > #3, #2 and #1 especially look a great value add.
> > >
> > > On #3 I think signing the digest would be easier in short run,
> encrypting
> > > will mean involving complex keystore/truststore setup.
> > >
> > > May be you already covered this in Recipes or elsewhere but still
> putting
> > > it here:
> > >
> > > It would be really cool if one could choose a custom data (like a
> > > String/Long value), I understand that this could be misused and
> > > misinterpreted as datastorage so may be there can be stricter limits on
> > the
> > > size of the custom payload. This might help Apps to integrate Gossip
> > > better.
> > >
> > > Just a thought !
> > >
> > > Best,
> > > Sandeep
> > >
> > > On Sun, Jan 29, 2017 at 10:25 PM, Edward Capriolo <
> edlinuxguru@gmail.com
> > >
> > > wrote:
> > >
> > > > We currently have almost 10 open tickets for features / improvements
> to
> > > > gossip, many are slated for the next release and we are on our way to
> > be
> > > > ahead of schedule with that.
> > > >
> > > > I wanted to pick everyone's brain as to where we should aim for.
> > > >
> > > > I think some larger general directions are below:
> > > >
> > > > 1) SWIM. https://www.cs.cornell.edu/~asdas/research/dsn02-swim.pdf
> > > >
> > > > This is a fairly large undertaking in terms of codifying the protocol
> > and
> > > > keeping the project elegant with two Failure Detectors
> > > >
> > > > 2) HTTP as transport
> > > >
> > > > Having two transports in the codebase is simple. I think this will go
> > > well
> > > >  HTTP clients do all the session/persistence. Transplanting Gossip to
> > > live
> > > > in a webapp wont be too bad but it might involve re-orging the
> project
> > a
> > > > bit into a multi-module maven project. I see a lot of upside here
> > > >
> > > > 3) Signed messages (https://issues.apache.org/jira/browse/GOSSIP-47)
> > > >
> > > > While I am not a super expert in keystores and such this strikes me
> as
> > > > interesting idea. Mostly because it allows peers to share info but
> also
> > > be
> > > > able to sign/verify/encrypt info as it moves between peers. I have
> > never
> > > > seen something quite like this so I think it is novel.
> > > >
> > > > 4) Recipes
> > > >
> > > > Building things like Ephemeral Nodes or Leader Election seem to be a
> > good
> > > > fit. Gossip should not be a database so this is a hard line to draw.
> > This
> > > > will take some research and expertise to implement correctly.
> > > >
> > > > 5) Second implementation
> > > >
> > > > Originally I planned to build out a second implementation in c, node,
> > or
> > > > python. This seems less appealing to me at the moment, but if Gossip
> > Java
> > > > gets too large/complex we will likely miss out window to do this.
> > > >
> > > > 6) something massive to spin up N instances in amazon and do testing
> > > >
> > > > This is something that needs to happen, maybe in two parts.
> > > >
> > > > 7) Other ideas? Let them fly.
> > > >
> > > > Thanks,
> > > > Edward
> > > >
> > >
> >
> > For #3 the problem is a digest is not easy. The reason is that hosts
> > communicate through each other. If there were three nodes A, B, and C,
> and
> > a message was sent from A -> B and then the message was sent from B -> C.
> > Node B would be able to change the data and the digest. What I want to do
> > is be able to ensure that the data is verified by A. This would be
> > something like a PGP email. I want to verify that the message is
> unaltered
> > and that it is from a specific sender.
> >
> > "It would be really cool if one could choose a custom data (like a
> > String/Long value), I understand that this could be misused and
> > misinterpreted as datastorage so may be there can be stricter limits on
> the
> > size of the custom payload. This might help Apps to integrate Gossip
> > better."
> >
> > I am unclear about what you are saying here. We can already gossip
> > arbitrary data between nodes.
> >
> > https://github.com/apache/incubator-gossip/blob/master/
> > src/test/java/org/apache/gossip/DataTest.java
> >
> > Thanks,
> > Edward
> >
>

" Verifying that the data comes from a specific node might be tricky."

For this feature to work the cluster nodes with either need one or more Pre
Shared Key or they would all have to agree on a (central) Certificate
Authority that could grant and verify. I would not expect this to be the
standard mode for most users, but I think it is fairly novel and would be
interesting to me.

Re: [DISCUSS] future directions

[Sandeep More <mo...@gmail.com>]

For #3 the problem is a digest is not easy. The reason is that hosts
communicate through each other. If there were three nodes A, B, and C, and
a message was sent from A -> B and then the message was sent from B -> C.
Node B would be able to change the data and the digest. What I want to do
is be able to ensure that the data is verified by A. This would be
something like a PGP email. I want to verify that the message is unaltered
and that it is from a specific sender.

SRM: I see, that would be complicated verifying the sender. I was thinking
of just verifying the signature on the hashes. Assuming we have a shared
secret amongst all the nodes verifying a signature would not be too
difficult. Verifying that the data comes from a specific node might be
tricky.

"It would be really cool if one could choose a custom data (like a
String/Long value), I understand that this could be misused and
misinterpreted as datastorage so may be there can be stricter limits on the
size of the custom payload. This might help Apps to integrate Gossip
better."

I am unclear about what you are saying here. We can already gossip
arbitrary data between nodes.

SRM: My bad, I missed this, thanks for pointing it out !

https://github.com/apache/incubator-gossip/blob/master/
src/test/java/org/apache/gossip/DataTest.java

Thanks,
Edward

On Mon, Jan 30, 2017 at 12:45 PM, Edward Capriolo <ed...@gmail.com>
wrote:

> On Mon, Jan 30, 2017 at 9:13 AM, Sandeep More <mo...@gmail.com>
> wrote:
>
> > This is exciting !
> >
> > #3, #2 and #1 especially look a great value add.
> >
> > On #3 I think signing the digest would be easier in short run, encrypting
> > will mean involving complex keystore/truststore setup.
> >
> > May be you already covered this in Recipes or elsewhere but still putting
> > it here:
> >
> > It would be really cool if one could choose a custom data (like a
> > String/Long value), I understand that this could be misused and
> > misinterpreted as datastorage so may be there can be stricter limits on
> the
> > size of the custom payload. This might help Apps to integrate Gossip
> > better.
> >
> > Just a thought !
> >
> > Best,
> > Sandeep
> >
> > On Sun, Jan 29, 2017 at 10:25 PM, Edward Capriolo <edlinuxguru@gmail.com
> >
> > wrote:
> >
> > > We currently have almost 10 open tickets for features / improvements to
> > > gossip, many are slated for the next release and we are on our way to
> be
> > > ahead of schedule with that.
> > >
> > > I wanted to pick everyone's brain as to where we should aim for.
> > >
> > > I think some larger general directions are below:
> > >
> > > 1) SWIM. https://www.cs.cornell.edu/~asdas/research/dsn02-swim.pdf
> > >
> > > This is a fairly large undertaking in terms of codifying the protocol
> and
> > > keeping the project elegant with two Failure Detectors
> > >
> > > 2) HTTP as transport
> > >
> > > Having two transports in the codebase is simple. I think this will go
> > well
> > >  HTTP clients do all the session/persistence. Transplanting Gossip to
> > live
> > > in a webapp wont be too bad but it might involve re-orging the project
> a
> > > bit into a multi-module maven project. I see a lot of upside here
> > >
> > > 3) Signed messages (https://issues.apache.org/jira/browse/GOSSIP-47)
> > >
> > > While I am not a super expert in keystores and such this strikes me as
> > > interesting idea. Mostly because it allows peers to share info but also
> > be
> > > able to sign/verify/encrypt info as it moves between peers. I have
> never
> > > seen something quite like this so I think it is novel.
> > >
> > > 4) Recipes
> > >
> > > Building things like Ephemeral Nodes or Leader Election seem to be a
> good
> > > fit. Gossip should not be a database so this is a hard line to draw.
> This
> > > will take some research and expertise to implement correctly.
> > >
> > > 5) Second implementation
> > >
> > > Originally I planned to build out a second implementation in c, node,
> or
> > > python. This seems less appealing to me at the moment, but if Gossip
> Java
> > > gets too large/complex we will likely miss out window to do this.
> > >
> > > 6) something massive to spin up N instances in amazon and do testing
> > >
> > > This is something that needs to happen, maybe in two parts.
> > >
> > > 7) Other ideas? Let them fly.
> > >
> > > Thanks,
> > > Edward
> > >
> >
>
> For #3 the problem is a digest is not easy. The reason is that hosts
> communicate through each other. If there were three nodes A, B, and C, and
> a message was sent from A -> B and then the message was sent from B -> C.
> Node B would be able to change the data and the digest. What I want to do
> is be able to ensure that the data is verified by A. This would be
> something like a PGP email. I want to verify that the message is unaltered
> and that it is from a specific sender.
>
> "It would be really cool if one could choose a custom data (like a
> String/Long value), I understand that this could be misused and
> misinterpreted as datastorage so may be there can be stricter limits on the
> size of the custom payload. This might help Apps to integrate Gossip
> better."
>
> I am unclear about what you are saying here. We can already gossip
> arbitrary data between nodes.
>
> https://github.com/apache/incubator-gossip/blob/master/
> src/test/java/org/apache/gossip/DataTest.java
>
> Thanks,
> Edward
>

Re: [DISCUSS] future directions

[Edward Capriolo <ed...@gmail.com>]

On Mon, Jan 30, 2017 at 9:13 AM, Sandeep More <mo...@gmail.com> wrote:

> This is exciting !
>
> #3, #2 and #1 especially look a great value add.
>
> On #3 I think signing the digest would be easier in short run, encrypting
> will mean involving complex keystore/truststore setup.
>
> May be you already covered this in Recipes or elsewhere but still putting
> it here:
>
> It would be really cool if one could choose a custom data (like a
> String/Long value), I understand that this could be misused and
> misinterpreted as datastorage so may be there can be stricter limits on the
> size of the custom payload. This might help Apps to integrate Gossip
> better.
>
> Just a thought !
>
> Best,
> Sandeep
>
> On Sun, Jan 29, 2017 at 10:25 PM, Edward Capriolo <ed...@gmail.com>
> wrote:
>
> > We currently have almost 10 open tickets for features / improvements to
> > gossip, many are slated for the next release and we are on our way to be
> > ahead of schedule with that.
> >
> > I wanted to pick everyone's brain as to where we should aim for.
> >
> > I think some larger general directions are below:
> >
> > 1) SWIM. https://www.cs.cornell.edu/~asdas/research/dsn02-swim.pdf
> >
> > This is a fairly large undertaking in terms of codifying the protocol and
> > keeping the project elegant with two Failure Detectors
> >
> > 2) HTTP as transport
> >
> > Having two transports in the codebase is simple. I think this will go
> well
> >  HTTP clients do all the session/persistence. Transplanting Gossip to
> live
> > in a webapp wont be too bad but it might involve re-orging the project a
> > bit into a multi-module maven project. I see a lot of upside here
> >
> > 3) Signed messages (https://issues.apache.org/jira/browse/GOSSIP-47)
> >
> > While I am not a super expert in keystores and such this strikes me as
> > interesting idea. Mostly because it allows peers to share info but also
> be
> > able to sign/verify/encrypt info as it moves between peers. I have never
> > seen something quite like this so I think it is novel.
> >
> > 4) Recipes
> >
> > Building things like Ephemeral Nodes or Leader Election seem to be a good
> > fit. Gossip should not be a database so this is a hard line to draw. This
> > will take some research and expertise to implement correctly.
> >
> > 5) Second implementation
> >
> > Originally I planned to build out a second implementation in c, node, or
> > python. This seems less appealing to me at the moment, but if Gossip Java
> > gets too large/complex we will likely miss out window to do this.
> >
> > 6) something massive to spin up N instances in amazon and do testing
> >
> > This is something that needs to happen, maybe in two parts.
> >
> > 7) Other ideas? Let them fly.
> >
> > Thanks,
> > Edward
> >
>

For #3 the problem is a digest is not easy. The reason is that hosts
communicate through each other. If there were three nodes A, B, and C, and
a message was sent from A -> B and then the message was sent from B -> C.
Node B would be able to change the data and the digest. What I want to do
is be able to ensure that the data is verified by A. This would be
something like a PGP email. I want to verify that the message is unaltered
and that it is from a specific sender.

"It would be really cool if one could choose a custom data (like a
String/Long value), I understand that this could be misused and
misinterpreted as datastorage so may be there can be stricter limits on the
size of the custom payload. This might help Apps to integrate Gossip
better."

I am unclear about what you are saying here. We can already gossip
arbitrary data between nodes.

https://github.com/apache/incubator-gossip/blob/master/src/test/java/org/apache/gossip/DataTest.java

Thanks,
Edward

Re: [DISCUSS] future directions

[Sandeep More <mo...@gmail.com>]

This is exciting !

#3, #2 and #1 especially look a great value add.

On #3 I think signing the digest would be easier in short run, encrypting
will mean involving complex keystore/truststore setup.

May be you already covered this in Recipes or elsewhere but still putting
it here:

It would be really cool if one could choose a custom data (like a
String/Long value), I understand that this could be misused and
misinterpreted as datastorage so may be there can be stricter limits on the
size of the custom payload. This might help Apps to integrate Gossip better.

Just a thought !

Best,
Sandeep

On Sun, Jan 29, 2017 at 10:25 PM, Edward Capriolo <ed...@gmail.com>
wrote:

> We currently have almost 10 open tickets for features / improvements to
> gossip, many are slated for the next release and we are on our way to be
> ahead of schedule with that.
>
> I wanted to pick everyone's brain as to where we should aim for.
>
> I think some larger general directions are below:
>
> 1) SWIM. https://www.cs.cornell.edu/~asdas/research/dsn02-swim.pdf
>
> This is a fairly large undertaking in terms of codifying the protocol and
> keeping the project elegant with two Failure Detectors
>
> 2) HTTP as transport
>
> Having two transports in the codebase is simple. I think this will go well
>  HTTP clients do all the session/persistence. Transplanting Gossip to live
> in a webapp wont be too bad but it might involve re-orging the project a
> bit into a multi-module maven project. I see a lot of upside here
>
> 3) Signed messages (https://issues.apache.org/jira/browse/GOSSIP-47)
>
> While I am not a super expert in keystores and such this strikes me as
> interesting idea. Mostly because it allows peers to share info but also be
> able to sign/verify/encrypt info as it moves between peers. I have never
> seen something quite like this so I think it is novel.
>
> 4) Recipes
>
> Building things like Ephemeral Nodes or Leader Election seem to be a good
> fit. Gossip should not be a database so this is a hard line to draw. This
> will take some research and expertise to implement correctly.
>
> 5) Second implementation
>
> Originally I planned to build out a second implementation in c, node, or
> python. This seems less appealing to me at the moment, but if Gossip Java
> gets too large/complex we will likely miss out window to do this.
>
> 6) something massive to spin up N instances in amazon and do testing
>
> This is something that needs to happen, maybe in two parts.
>
> 7) Other ideas? Let them fly.
>
> Thanks,
> Edward
>