On Thu, Sep 19, 2013 at 10:48 PM, Melvin Carvalho <[email protected]>wrote:
> On 19 September 2013 21:51, Nick Jennings <[email protected]> wrote: > >> On Wed, Sep 18, 2013 at 6:23 PM, Melvin Carvalho < >> [email protected]> wrote: >> >>> On 18 September 2013 18:06, Nick Jennings <[email protected]> wrote: >>> >>>> On Wed, Sep 18, 2013 at 5:59 PM, Melvin Carvalho < >>>> [email protected]> wrote: >>>> >>>>> On 18 September 2013 15:47, Nick Jennings <[email protected]>wrote: >>>>> >>>>>> On Wed, Sep 18, 2013 at 2:11 PM, Melvin Carvalho < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> On 10 September 2013 19:45, Nick Jennings <[email protected]>wrote: >>>>>>> >>>>>>>> Hi Carlo, nice to see this work being done, specifically a >>>>>>>> distributed pubsub implementation. Do you have a repo where this is >>>>>>>> being >>>>>>>> developed? Also is this just the beginning or is there something >>>>>>>> working >>>>>>>> already? >>>>>>>> >>>>>>>> One question regarding ActivityStreams below: >>>>>>>> >>>>>>>> On Tue, Sep 10, 2013 at 6:41 PM, carlo von lynX < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> At the same time as the implementation of this fundamental piece >>>>>>>>> of the GNU Internet is taking place, we will soon present the >>>>>>>>> equivalent of >>>>>>>>> the ActivityStreams protocol, enabling developers to create user >>>>>>>>> interfaces >>>>>>>>> and further applications on top of an infrastructure that provides >>>>>>>>> similar >>>>>>>>> social functionality as the social services we are familiar with, but >>>>>>>>> in a >>>>>>>>> distributed and encrypted fashion. >>>>>>>>> >>>>>>>>> >>>>>>>> I'm unclear why it makes sense to re-invent the ActivityStreams >>>>>>>> protocol? There is nothing in it's nature that defines infrastructure, >>>>>>>> so >>>>>>>> being distributed and/or encrypted is something that can build on-top >>>>>>>> of >>>>>>>> the existing protocol, also something I'm working closely with in >>>>>>>> Sockethub. >>>>>>>> >>>>>>> >>>>>>> Activity streams is not a protocol >>>>>>> >>>>>>> >>>>>> That depends on who you ask, from the Wikipedia page: >>>>>> >>>>>> " The Activity >>>>>> Streams<http://en.wikipedia.org/wiki/Activity_Streams_%28format%29>project, >>>>>> for example, is an effort to develop an activity stream >>>>>> protocol <http://en.wikipedia.org/wiki/Protocol_%28computing%29> to >>>>>> syndicate activities across social >>>>>> Web<http://en.wikipedia.org/wiki/Social_Web>applications. >>>>>> [2] <http://en.wikipedia.org/wiki/Activity_stream#cite_note-2> " >>>>>> >>>>>> While I agree there's more to a protocol than just the data format, >>>>>> there's definitely work being done to make the content of the AS objects >>>>>> indicate either intent or result, which lays the groundwork for a >>>>>> protocol. >>>>>> >>>>>> >>>>>> It's a data serialization. >>>>>>> >>>>>>> >>>>>> While basically true, I'm not sure that's a descriptive enough word, >>>>>> as JSON itself is a data serialization method. >>>>>> >>>>>> I was using the same words Carlo used to reference it, and I don't >>>>>> have a strong opinion either way, but I don't think using the term >>>>>> serialization makes it any clearer. >>>>>> >>>>>> >>>>>> The current version relies on a proprietary central registry of verbs >>>>>>> which does not (currently) support any form of encryption as far as I >>>>>>> know >>>>>>> >>>>>> >>>>>> If AS is a protocol, then I don't understand why a definition of >>>>>> verbs should be considered proprietary or centralized - in the same way >>>>>> that any other protocol, be it HTTP, SMTP or FINGER, has a set of defined >>>>>> commands. >>>>>> >>>>>> If AS is a data serialization mechanism, I don't understand how it >>>>>> can written it to "support for any form of encryption". Are the two >>>>>> related? Does JSON itself have built in support for encryption that AS >>>>>> lacks? Could you give me some examples of data serialization which >>>>>> supports >>>>>> encryption? >>>>>> >>>>>> Maybe I misunderstand what is meant by the original statement by >>>>>> Carlo, but that's why I asked in the first place. >>>>>> >>>>> >>>>> "Depending on who you speak to" is hedging your bets a bit! >>>>> >>>>> I was speaking to you, what's your take? Is activity streams a >>>>> protocol or not? >>>>> >>>>> >>>> I'm more interested in my original question, not whether AS is a >>>> protocol or not. Like I said, I don't have a strong opinion either way. >>>> >>>> >>> OK, then why did you argue the case? >>> >>> >> I'm not arguing any case, I just pointed out that many people, including >> the OP and Wikipedia refer to AS as a protocol. I really don't care what >> people call it. Maybe you could ask Carlo why he chose those words. >> >> >> HTTP is the protocol, Activity Streams is the serialization. A >>> (communications) protocol is way more complex than a serialization. >>> >> >> I'm fully aware of the differences between serialization and protocols. >> >> >> >>> And if this is what you want to do with sockethub / activity stream, I >>> think you're going to run into major issues. >>> >>> My comment was that the Activity Streams specification does not mention >>> encryption anywhere. >>> >>> You are the person that said: "being distributed and/or encrypted is >>> something that can build on-top of the existing protocol" ... "something >>> I'm working closely with in Sockethub" >>> >>> I have doubts about this comment ... how do you intend to build >>> encryption on-top of Activity Streams? >>> >> >> You have doubts that I'm working closely with implementing encryption >> wherever I can? I'm sorry to hear that, but I asked my original question to >> perhaps gain some insight into what shortcomings AS has in regards to being >> implemented in a distributed, encrypted infrastructure. >> > > i asked how you are working to build encryption on top, in line with our > claim > I'm not working to build encryption on-top of AS, but I am working with encrypting data and that data happens to be Activity Streams-like objects. In fact all data that comes into Sockethub is immediately encrypted. (and yes, I know that's not good enough, which is why GNUnet is aiming to be what it's aiming to be) I'm not a security expert and make no claims to any encryption sophistication to the levels that GNUnet is aiming. In fact I chimed in this thread not to argue semantics with you, believe it or not, but in the hopes I might learn something new about shortcomings of AS from Carlos perspective. Instead it seems I've caught a troll. :) >> As in, what characteristics about a protocol or serialization method lend >> itself to encryption or make it more difficult, and why does it really >> matter what a payload is within an encrypted channel. >> >> I think it should be considered with care when deciding to re-implement >> something that already exists, like AS, to serve the same purpose. So I was >> curious as to what the thought process was, and asked the question in the >> hopes I might learn something new. >> >> I don't really want to continue to get caught up in semantics with you >> about wording of protocol vs. serialization, as it's completely unrelated >> to my question. >> > > activity streams itself is a reinvention ... you are saying pick one > reinvention over another and at the same time not to reinvent ... it's a > contradiction > I'm not saying anything of the kind, please don't put words in my mouth, and please don't assume I'm evangelizing AS. The point I made you would, and have, agreed with - or made yourself - on several occasions. I don't care if it's AS or HTTP or FINGER or JSON, I think it should be thought through and hopefully discussed as to the reasoning for re-creating something. As I was not part of that conversation I asked that I might learn something, but now I'm repeating myself. http://xkcd.com/927/ I answered your question (re: encryption) above, because you asked, though based on your comments so far, I question whether you asked for any reason other than to find more avenues to attack... Sorry to say but I find this thread completely pointless and not conducive to a constructive conversation. Let's end it shall we? Cheers Nick
