Login

Redecentralize

We’ve had enough of digital monopolies and surveillance capitalism. We want an alternative world that works for everyone, just like the original intention of the web and net.

We seek a world of open platforms and protocols with real choices of applications and services for people. We care about privacy, transparency and autonomy. Our tools and organisations should fundamentally be accountable and resilient.

Home
Paul Frazee [LibreList] Re: [redecentralize] Introduction 2014-01-06 13:46:47
Ierymenko < adam.ierymenko@zerotier.com > wrote: I absolutely agree. As I've designed ZeroTier One I've had an eye toward further decentralization, designing the protocol so that it will be achievable with as little pain as possible. I have a mental image of what it might look like /...\ protocol is designed to enable it with only the addition of new message types-- existing protocol messages should work fine and not need to be altered much (if at all). A bit about the ZT1 design: Supernodes in ZeroTier One are just regular nodes running the exact same code /...\ propagating multicasts to multicast subscribers that are more frequent partners in communication. I chose to virtualize at layer 2 because this enables any protocol to work... you could even play IPX LAN games over this. :) On Jan 6, 2014, at 11:18 AM, Paul Frazee < pfrazee@gmail.com > wrote
Adam Ierymenko [LibreList] Re: [redecentralize] Introduction 2014-01-06 11:40:41
absolutely agree. As I've designed ZeroTier One I've had an eye toward further decentralization, designing the protocol so that it will be achievable with as little pain as possible. I have a mental image of what it might look like, and the protocol is designed to enable /...\ with only the addition of new message types-- existing protocol messages should work fine and not need to be altered much (if at all). A bit about the ZT1 design: Supernodes in ZeroTier One are just regular nodes running the exact same code as the regular client that are running /...\ propagating multicasts to multicast subscribers that are more frequent partners in communication. I chose to virtualize at layer 2 because this enables any protocol to work... you could even play IPX LAN games over this. :) On Jan 6, 2014, at 11:18 AM, Paul Frazee < pfrazee@gmail.com > wrote
Adam Ierymenko [LibreList] Re: [redecentralize] Introduction 2014-01-06 11:50:49
Ierymenko < adam.ierymenko@zerotier.com > wrote: I absolutely agree. As I've designed ZeroTier One I've had an eye toward further decentralization, designing the protocol so that it will be achievable with as little pain as possible. I have a mental image of what it might look like /...\ protocol is designed to enable it with only the addition of new message types-- existing protocol messages should work fine and not need to be altered much (if at all). A bit about the ZT1 design: Supernodes in ZeroTier One are just regular nodes running the exact same code /...\ propagating multicasts to multicast subscribers that are more frequent partners in communication. I chose to virtualize at layer 2 because this enables any protocol to work... you could even play IPX LAN games over this. :) On Jan 6, 2014, at 11:18 AM, Paul Frazee < pfrazee@gmail.com > wrote
Paul Frazee [LibreList] Re: [redecentralize] Applying User-Agent Behaviors in Web Applications to Enable Runtime Extension 2014-03-11 10:45:08
looking for reltypes that it understands, and then begins communicating with the endpoints of those links according to their reltype specs. By publishing Askemos' protocols as reltypes, you standardize the protocols. For a simple example, if Askemos used a "heartbeat" protocol in which ping messages need to be exchanged regularly /...\ write a spec for the client and the server and upload it at, say, askemos.org/rel/heartbeat . A server which follows the protocol would link to itself with `rel=" askemos.org/rel/heartbeat "`. A client which uses heart-beating servers would seek out that link, then (for instance, if this were the protocol /...\ have to be a Citibank dev to dev Citibank. I'd need to research it more deeply, but I suspect that Askemos' protocols could be implemented in this extensions-architecture as a set of reltypes. It might be used to cluster multiple Worker scripts and remote services which all implement
Paul Frazee [LibreList] Re: [redecentralize] Introduction 2014-01-06 13:53:30
Ierymenko < adam.ierymenko@zerotier.com > wrote: I absolutely agree. As I've designed ZeroTier One I've had an eye toward further decentralization, designing the protocol so that it will be achievable with as little pain as possible. I have a mental image of what it might look like /...\ protocol is designed to enable it with only the addition of new message types-- existing protocol messages should work fine and not need to be altered much (if at all). A bit about the ZT1 design: Supernodes in ZeroTier One are just regular nodes running the exact same code /...\ propagating multicasts to multicast subscribers that are more frequent partners in communication. I chose to virtualize at layer 2 because this enables any protocol to work... you could even play IPX LAN games over this. :) On Jan 6, 2014, at 11:18 AM, Paul Frazee < pfrazee@gmail.com > wrote
Feross Aboukhadijeh [LibreList] Re: [redecentralize] Hello from WebTorrent 2013-12-31 17:54:38
WebRTC can speak whatever protocol you want (you can design your own). WebTorrent is going to speak the same BitTorrent protocol, as much as possible. WebRTC does not allow you to open arbitrary TCP or UDP sockets, which is what I think you're asking. Existing torrent clients will need /...\ Francis Irving < francis@flourish.org > wrote: Feross, quick question about this... Can WebRTC Data Channels natively speak arbitary protocols, so they can just implement the regular BitTorrent protocol? Or will existing BitTorrent clients need updating? Francis On Sun, Dec 08, 2013 at 03:31:00PM -0800, Feross Aboukhadijeh wrote
Paul Frazee [LibreList] Re: [redecentralize] Applying User-Agent Behaviors in Web Applications to Enable Runtime Extension 2014-03-10 11:51:10
have to be a Citibank dev to dev Citibank. I'd need to research it more deeply, but I suspect that Askemos' protocols could be implemented in this extensions-architecture as a set of reltypes. It might be used to cluster multiple Worker scripts and remote services which all implement /...\ This is basically the same question we had to solve when looking into "how do those nodes run application code?". Askemos - being only the protocol level - just goes so far to say: (a) an app might have local state, the implementation is responsible to apply updates requested by the application /...\ after having run the agreement protocol) and (b) no app shall be able modify other app's state or even it's own state bypassing the agreement step. Insofar your sandboxing text reads very related to our implementation. Obviously. Ah, yeah: applications in Askemos can communicate with each other
Eric Mill [LibreList] Re: [redecentralize] Spring of User Experience 2014-03-03 12:22:12
left where you must trust your admin. It's a fundamental theorem of cryptography that "trusted third parties" are never necessary in any protocol. The difficult question is to build non-TTP protocols that are *efficient*. This is beyond my knowledge to prove, but it's out there /...\ pretty accessible to anyone with a moderate (ugrad) maths background, and is a good introduction to these topics. I'm not talking about cryptographic _protocols_ at all.  I'm talking about the hardware you're using.  If you have some hardware and there is some administrator /...\ admin is not you, then your admin is a trusted third party to you. Regarding Efficient non-TTP protocols: Which purpose do you have in mind? The rest of your email, was uncorrelated snippets of security-sounding concepts, that don't have much connection to the field as it exists
Jörg F. Wittenberger [LibreList] Re: [redecentralize] Spring of User Experience 2014-03-03 16:07:34
left where you must trust your admin. It's a fundamental theorem of cryptography that "trusted third parties" are never necessary in any protocol. The difficult question is to build non-TTP protocols that are *efficient*. This is beyond my knowledge to prove, but it's out there /...\ pretty accessible to anyone with a moderate (ugrad) maths background, and is a good introduction to these topics. I'm not talking about cryptographic _protocols_ at all.  I'm talking about the hardware you're using.  If you have some hardware and there is some administrator /...\ admin is not you, then your admin is a trusted third party to you. Regarding Efficient non-TTP protocols: Which purpose do you have in mind? The rest of your email, was uncorrelated snippets of security-sounding concepts, that don't have much connection to the field as it exists
Adam Ierymenko [LibreList] Re: [redecentralize] snow: a new distributed secure virtual network 2014-07-04 12:31:33
firewall! But security! But... umm... yeah. (1) I call what you describe "everything protocols" -- SSH for example can basically do everything. As a result of the firewall cargo cult we are in an arms race with ourselves to defeat our own security measures. We block things, then design protocols /...\ actually using HTTP, now your messaging app is vulnerable to XSRF for no good reason. Meanwhile they add kitchen sink support to the HTTP protocol in order to support all of this, increasing the attack surface dramatically. Meanwhile in order to do DPI against HTTPS the enterprise
Jörg F. Wittenberger [LibreList] Re: [redecentralize] Applying User-Agent Behaviors in Web Applications to Enable Runtime Extension 2014-03-10 14:51:13
basically the same question we had to solve when looking into "how do those nodes run application code?". Askemos - being only the protocol level - just goes so far to say: (a) an app might have local state, the implementation is responsible to apply updates requested by the application /...\ after having run the agreement protocol) and (b) no app shall be able modify other app's state or even it's own state bypassing the agreement step. Insofar your sandboxing text reads very related to our implementation. Obviously. Ah, yeah: applications in Askemos can communicate with each other /...\ copying never happened, still there are multiple copies...) > Servers may apply clustering algorithms to share state authority, and so (I suspect) Askemos' protocols should be applicable to them. Servers remain a network primitive for more complex topologies. Looks still more interesting. > Another notable aspect of trust is data
Adam Ierymenko [LibreList] Re: [redecentralize] Thoughts on decentralization: "I want to believe." 2014-08-04 16:06:56
exactly, but close. CJDNS is a mesh protocol that creates a single L3 IPv6 network. ZeroTier One is a hybrid peer to peer protocol that creates virtual Ethernet networks (plural). ZeroTier is more like SDN for everyone, everywhere. (SDN is software defined networking, and refers to the creation of software /...\ Wittenberger": Adam, I've got a question: … In this blog post you wrote: > I designed the protocol to be capable of evolving toward a more decentralized design in the future without disrupting existing users, but that's where it stands today
holger krekel [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-02 19:16:07
allowing it to build new services (GOTO 1) IOW I think there is more to decentralization than the network topology and the raw IP protocol. However I do agree with you, Adam, that NATs are making it even harder to grow sustained decentralized deployments of software and services /...\ real address, and improve device perimeter security enough that firewalls can be junked. > > The other great thing about IP vs. those complicated protocols is that it’s all open and simple and straightforward. All those complicated, fragmented p2p monstrosities have their own peculiar APIs and very complex /...\ serve as a stepping stone *out* of the fragmented broken-IP world— to offer an anti-lock-in path back to open protocols over a true many-to-many flat Internet address space. It’s a project/product designed to make itself obsolete. > > -Adam
Geoffroy Couprie [LibreList] Re: [redecentralize] Spring of User Experience 2014-02-28 19:33:08
problem between security and UX often bogs down to the approach in development. Crypto apps have a bottom up approach: we have a crypto protocol, let's build a UI around. That's what we saw with GPG, client cert authentication, etc. When you take a top down approach /...\ need more crypto wrappers to provide usable APIs (good algorithms default, sane use of  RNG, etc) with clearly defined boundaries (embedding the protocol's state machine instead of asking the developer to write it) and good abstractions (the developer should not have to worry about repeating /...\ Python cryptography project. It takes time to write those abstractions, but it is rewarding. Also, we need clear definitions of what a protocol can and cannot do. there are a lot of wonderful crypto primitives that could be exploited if people knew about it, instead of writing yet another broken
Adam Ierymenko [LibreList] Re: [redecentralize] Thoughts on decentralization: "I want to believe." 2014-08-05 11:57:52
Eric On Mon, Aug 4, 2014 at 7:06 PM, Adam Ierymenko < adam.ierymenko@zerotier.com > wrote: Not exactly, but close. CJDNS is a mesh protocol that creates a single L3 IPv6 network. ZeroTier One is a hybrid peer to peer protocol that creates virtual Ethernet networks (plural). ZeroTier is more /...\ Wittenberger": Adam, I've got a question: … In this blog post you wrote: > I designed the protocol to be capable of evolving toward a more decentralized design in the future without disrupting existing users, but that's where it stands today. -- konklone.com | @konklone
Eric Mill [LibreList] Re: [redecentralize] GNU Internet Stack / youbroketheinternet.org 2013-12-29 15:26:45
thing that rubs me the wrong way is lumping in JSON and XML as things that have to be replaced with a "smarter" protocol, PSYC . Why is this in here? JSON is an open, simple, intentionally dumb format that is ubiquitous and incredibly useful. It certainly has downsides! But there /...\ reason Protocol Buffers  hasn't taken over the world, which is that it requires more upfront investment of time and complexity, is more rigid, etc. I don't know, I don't want to criticize a great effort over maybe a small thing, but it's already asking /...\ start over on a number of things. If the effort wants to gain traction, maybe consider taking one of the successful, ownerless, omnipresent protocols we've managed to converge on and build on top of it. Pick your battles! On Sun, Dec 29, 2013 at 1:08 PM, Benjamin Heitmann
Paul Frazee [LibreList] Re: [redecentralize] GNU Internet Stack / youbroketheinternet.org 2013-12-30 11:45:20
think it'll be difficult to make feature parity with HTTP from greenfield projects, which is why I'm skeptical. For instance, GNUnet's protocol is restricted to file-sharing, while HTTP can do file sharing, social networking, video-streaming, etc with dynamic backends. So I'm inclined /...\ keep HTTP, improve on its usage model, then mix in new protocols like GNUnet that HTTP absolutely can't mimic. Regarding WebRTC, the central dependency is signal routing and IP discovery. You can distribute that system with lots of HTTPS hosts, but you still need to address vulnerabilities /...\ Irving < francis@flourish.org > wrote: My instinct is that long game, they're right and HTTP is fatally flawed. It is a fundamentally centralizing protocol - the domain in a URL is both the name of the resource *and* the place you go to get that resource. Short term is another
Eric Mill [LibreList] Re: [redecentralize] Thoughts on decentralization: "I want to believe." 2014-08-05 00:48:45
Eric On Mon, Aug 4, 2014 at 7:06 PM, Adam Ierymenko < adam.ierymenko@zerotier.com > wrote: Not exactly, but close. CJDNS is a mesh protocol that creates a single L3 IPv6 network. ZeroTier One is a hybrid peer to peer protocol that creates virtual Ethernet networks (plural). ZeroTier is more /...\ Wittenberger": Adam, I've got a question: … In this blog post you wrote: > I designed the protocol to be capable of evolving toward a more decentralized design in the future without disrupting existing users, but that's where it stands today. -- konklone.com | @konklone
Michiel de Jong [LibreList] Re: [redecentralize] heads-up - draft api for cloud-to-cloud sharing standard 2015-08-06 19:06:34
concept proxies that can convert for instance a remoteStorage or Cozy server into something that exposes the endpoints required by the ownCloud federation protocol. We also already produced an IETF internet-draft giving an overview of the steps involved in decentralized sharing: http://tools.ietf.org/html/draft-dejong-decentralized-sharing-00 Current work within the group /...\ mainly focuses on using Cozy (or ownCloud) to select for instance a photo you want to share, and then using the MicroPub protocol ( http://indiewebcamp.com/micropub ) to post that photo to an IndieWeb-compatible blog, for instance your Known website ( https://withknown.com ). Cheers, Michiel
Adam Ierymenko [LibreList] Re: [redecentralize] Thoughts on decentralization: "I want to believe." 2014-08-13 21:04:47
think someone is going to successfully attack Bitcoin. What happens then? I don't know. It has some value as a wire transfer protocol if nothing else, but the sheen will certainly wear off. > The ideal would be for nodes to only trust a peer to relay data /...\ control over it. I like this...especially the part about shrinking the problem. It reminds me of how old NNTP and IRC and similar protocols were run. You had a network of servers run by admin volunteers, so the trust problem was manageable. But there was no king
MikedePlume [LibreList] Re: [redecentralize] Thoughts on decentralization: "I want to believe." 2014-08-20 12:04:36
cities, where everyone is a stranger, and police are required. To bring the point home, we can consider a market as a collection of protocols. This conversation, or the re-decentralise thing, probably started by assuming these protocols all work perfectly, as per Hayeck. Clearly not a worker. We need
Adam Ierymenko [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-02 11:07:42
device a real address, and improve device perimeter security enough that firewalls can be junked. The other great thing about IP vs. those complicated protocols is that it’s all open and simple and straightforward. All those complicated, fragmented p2p monstrosities have their own peculiar APIs and very complex /...\ serve as a stepping stone *out* of the fragmented broken-IP world— to offer an anti-lock-in path back to open protocols over a true many-to-many flat Internet address space. It’s a project/product designed to make itself obsolete. -Adam
Francis Irving [LibreList] Re: [redecentralize] Hello from WebTorrent 2013-12-30 12:09:19
Feross, quick question about this... Can WebRTC Data Channels natively speak arbitary protocols, so they can just implement the regular BitTorrent protocol? Or will existing BitTorrent clients need updating? Francis On Sun, Dec 08, 2013 at 03:31:00PM -0800, Feross Aboukhadijeh wrote: > Hey everyone! I think Redecentralize
Adam Ierymenko [LibreList] Re: [redecentralize] Introduction 2014-01-06 10:51:29
pursuing a strategy of "make it work, then make it more decentralized." There seems to be an exponential difficulty curve re: *completely* decentralizing a protocol and that in turn comes from some fundamental constraints in information theory such as the CAP theorem. My goal is for ZeroTier /...\ very fast, and doing that without any centralized POP is really hard. In the future it would be possible to further decentralize the protocol by introducing something like a fast Kad network, a trust system for selecting supernodes in a decentralized manner, etc. (2) I do plan to have both
Ximin Luo [LibreList] Re: [redecentralize] Spring of User Experience 2014-03-03 14:06:48
Ximin Luo [LibreList] Re: [redecentralize] Spring of User Experience 2014-03-03 14:17:23
Jörg F. Wittenberger [LibreList] Re: [redecentralize] Thoughts on decentralization: "I want to believe." 2014-08-03 11:31:11
some thoughts I've wanted to get down for a while: http://adamierymenko.com/decentralization-i-want-to-believe/ In this blog post you wrote: > I designed the protocol to be capable of evolving toward a more decentralized design in the future without disrupting existing users, but that's where it stands today /...\ need to register one such identifier per peer in a DHT. B) We need some kind of byzantine (Paxos alike) protocol, which is capable to convey hash verifying agreement on the proposed update.  (This is slightly more than most paxos implementations provide, since those are for some reason beyond
Paul Frazee [LibreList] Re: [redecentralize] Introduction 2014-01-06 13:18:13
pursuing a strategy of "make it work, then make it more decentralized." There seems to be an exponential difficulty curve re: *completely* decentralizing a protocol and that in turn comes from some fundamental constraints in information theory such as the CAP theorem. My goal is for ZeroTier /...\ very fast, and doing that without any centralized POP is really hard. In the future it would be possible to further decentralize the protocol by introducing something like a fast Kad network, a trust system for selecting supernodes in a decentr alized manner, etc. (2) I do plan to have
Jörg F. Wittenberger [LibreList] Re: [redecentralize] Thoughts on decentralization: "I want to believe." 2014-08-05 12:31:45
sling packets is simply off the table, since it would kill battery life and eat up cellular data quotas. That basically eliminates every mesh protocol I know about, every DHT, etc. from consideration for mobile. I did not want to say that efficiency is not important
Adam Ierymenko [LibreList] Re: [redecentralize] Thoughts on decentralization: "I want to believe." 2014-08-19 12:52:55
relayed then they also know how much data. But that’s all they know. They don’t know the protocol, the port, or the content of that data. They’re *pretty* blind. I have a suspicion it might be possible to do better than that, to make
David Geib [LibreList] Re: [redecentralize] Thoughts on decentralization: "I want to believe." 2014-08-20 00:56:27
Seems to me that they do otherwise cooperation becomes difficult (game theory territory). That's probably true in an "all must agree on what protocol to use" sense but I don't think dynamic global consensus is actually required in general. The things like that which everyone has to agree
David Geib [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-08-29 19:55:53
point is to make a trivial and goofy but hopefully hard-hitting demo of the fact that IP is in fact the P2P protocol we’re looking for (provided it can run without a ton of walls and moats in the way). -Adam
Eric Mill [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-08-31 21:36:34
point is to make a trivial and goofy but hopefully hard-hitting demo of the fact that IP is in fact the P2P protocol we’re looking for (provided it can run without a ton of walls and moats in the way). -Adam
Adam Ierymenko [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-02 12:35:23
build new services (GOTO 1) > > IOW I think there is more to decentralization than the network topology > and the raw IP protocol. However I do agree with you, Adam, that NATs > are making it even harder to grow sustained decentralized deployments of > software and services
David Geib [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-02 23:05:21
system - >> that depends on people >> freely choosing to run your program, and also choosing not to abuse >> your protocol, or try to >> trick or deny service to other nodes in the network. You can't apply >> coersion to incent cooperation
Dominic Tarr [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-02 14:44:40
true p2p system, a decentralized system - that depends on people freely choosing to run your program, and also choosing not to abuse your protocol, or try to trick or deny service to other nodes in the network. You can't apply coersion to incent cooperation, you probably don't know
Richard D. Bartlett [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-03 11:08:18
true p2p system, a decentralized system - that depends on people freely choosing to run your program, and also choosing not to abuse your protocol, or try to trick or deny service to other nodes in the network. You can't apply coersion to incent cooperation, you probably don't know
Paul Frazee [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-02 18:25:57
true p2p system, a decentralized system - that depends on people freely choosing to run your program, and also choosing not to abuse your protocol, or try to trick or deny service to other nodes in the network. You can't apply coersion to incent cooperation, you probably don't know
Dominic Tarr [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-03 11:04:25
depends on people >> >> freely choosing to run your program, and also choosing not to abuse >> >> your protocol, or try to >> >> trick or deny service to other nodes in the network. You can't apply
Jörg F. Wittenberger [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-04 13:20:45
eventually starve for being not profitable. > IOW I think there is more to decentralization than the network topology > and the raw IP protocol. However I do agree with you, Adam, that NATs > are making it even harder to grow sustained decentralized deployments of > software and services
Jörg F. Wittenberger [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-04 14:49:06
system, a decentralized system - > that depends on people > freely choosing to run your program, and also choosing not to abuse > your protocol, or try to > trick or deny service to other nodes in the network. Who said that a user should ever *depend* on some people
Jörg F. Wittenberger [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-04 15:07:09
here for byzantine fault tolerance), they will be identical. So we can checksum and verify. (In practice that's an integral part of the protocol.) If Bob chooses to expand the list of "notaries" (as we call those devices commissioned to hold some data) than the newly added
P S [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-06 13:40:03
Take a look at gossip protocols, epidemic models and probabilistic guarantees, e.g. Xerox Clearinghouse and NNTP. http://www.cs.cornell.edu/home/rvr/papers/UsingEpidemic.pdf https://www.cs.duke.edu/~chase/cps212-archive/slides/entropy6.pdf https://courses.engr.illinois.edu/cs525/sp2010/Presentation_525.pdf https://www.academia.edu/2601544/Replication_Optimistic_approaches http://bitsavers.informatik.uni-stuttgart.de/pdf/xerox/parc/techReports/CSL-89-1_Epidemic_Algorithms_for_Replicated_Database_Maintenance.pdf http://bitsavers.informatik.uni-stuttgart.de/pdf/xerox/parc/techReports/OPD-T8103_The_Clearinghouse.pdf
Richard Dent [LibreList] Unsubscribe 2014-09-06 18:41:15
06/09/2014 18:40, P S wrote: Take a look at gossip protocols, epidemic models and probabilistic guarantees, e.g. Xerox Clearinghouse and NNTP. http://www.cs.cornell.edu/home/rvr/papers/UsingEpidemic.pdf https://www.cs.duke.edu/~chase/cps212-archive/slides/entropy6.pdf https://courses.engr.illinois.edu/cs525/sp2010 /Presentation_525.pdf https://www.academia.edu/2601544/Replication_Optimistic_approaches http://bitsavers.informatik.uni-stuttgart.de/pdf/xerox/parc/techReports/CSL-89-1_Epidemic_Algorithms_for_Replicated_Database_Maintenance.pdf http://bitsavers.informatik.uni-stuttgart.de/pdf/xerox/parc/techReports/OPD-T8103_The_Clearinghouse.pdf
Jörg F. Wittenberger [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-09 11:30:40
description of the algorithm? A high-level description http://askemos.org/index.html?_v=wiki&_id=617 more technical here http://ball.askemos.org/?_v=wiki&_id=1339 (follow "consensus and synchronization protocol" for state machine replication > Also, regards your notary system: how are notaries assigned to > officiate a particular "place" > (is that correct
Michael Rogers [LibreList] Re: [redecentralize] Tribler and Dispersy 2014-09-12 16:19:41
BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 06/09/14 19:23, P S wrote: > Has anyone used Tribler or reviewed the protocols and technical > papers? > > https://github.com/Tribler/tribler/wiki I'm a part-time member of the research group that produces Tribler - I don't work on Tribler
Dominic Tarr [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-02 16:55:31
system - >> that depends on people >> freely choosing to run your program, and also choosing not to abuse >> your protocol, or try to >> trick or deny service to other nodes in the network. You can't apply >> coersion to incent cooperation
Francis Irving [LibreList] Re: [redecentralize] GNU Internet Stack / youbroketheinternet.org 2013-12-30 11:42:22
instinct is that long game, they're right and HTTP is fatally flawed. It is a fundamentally centralizing protocol - the domain in a URL is both the name of the resource *and* the place you go to get that resource. Short term is another matter. There are lots of incremental
maze@strahlungsfrei.de [LibreList] Re: [redecentralize] What *else* are people doing with blockchains? 2014-01-02 16:07:02
nicknames in the network. Quoting the FAQ: "Bitcoin, in the sense of the digital currency, is not used at all. However, the Bitcoin protocol and the implementation of the neat idea of block chain is on the basis of twister. The block chain provides a sort of distributed notary
Ira [Email] There's more to decentralisation 2018-09-25 13:51:19.9682
through the use of technology - such as promoting agency, privacy, collaboration and choice An ecosystem of alternatives that work together and collaborate through open protocols is more compelling than one killer app Full post is here: https://medium.com/coinmonks/how-decentralised-are-you-a6539eeb27ff Would love your thoughts and ideas on this and what
MikedePlume [LibreList] Re: [redecentralize] GNU Internet Stack / youbroketheinternet.org 2014-01-01 11:50:23
wrote: > My instinct is that long game, they're right and HTTP is fatally > flawed. > > It is a fundamentally centralizing protocol - the domain in a URL is > both the name of the resource *and* the place you go to get that > resource
Paul Frazee [LibreList] Re: [redecentralize] Applying User-Agent Behaviors in Web Applications to Enable Runtime Extension 2014-03-09 09:25:35
part of the network, and so origin is more granular. Servers may apply clustering algorithms to share state authority, and so (I suspect) Askemos' protocols should be applicable to them. Servers remain a network primitive for more complex topologies. Another notable aspect of trust is data-containment, which Workers solve
Richard Marr [LibreList] Re: [redecentralize] GNU Internet Stack / youbroketheinternet.org 2014-01-05 11:35:55
wrote: > My instinct is that long game, they're right and HTTP is fatally > flawed. > > It is a fundamentally centralizing protocol - the domain in a URL is > both the name of the resource *and* the place you go to get that > resource
Francis Irving [LibreList] Re: [redecentralize] "Old" but good article on "The Internet's Original Sin" 2015-08-25 21:12:46
shipped.   http://www.w3.org/ECommerce/Micropayments/   Unlike the various startups that have tried to capture this territory, at least decentralized cryptocurrencies are a protocol, so once one reaches critical mass for micropayments it can truly take off...   Francis
Paul Frazee [LibreList] Re: [redecentralize] Net Neutrality Ruling, Internet Interprets Censorship as Damage, There are no Captains, Decentralize Everything, etc. 2014-01-14 14:38:21
least in my view.  But it also made me think some more about this and realize that if we want decentralized protocols / solutions to spread at all, we have to do a way better job at being good advocates for them and talking about them incessantly to everyone
Adam Ierymenko [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-08-29 15:17:09
point is to make a trivial and goofy but hopefully hard-hitting demo of the fact that IP is in fact the P2P protocol we’re looking for (provided it can run without a ton of walls and moats in the way). -Adam
Kiktron RAKO [LibreList] Re: [redecentralize] 2014-06-06 16:04:20
around your data (no silo). For now we lack social features, but we work on it with a techno called XDI (a format and protocol for semantic data interchange) wich is promoted by the startup Respect Network . We have a B2B2C business model, we have some promising clients (OVH, Orange
hellekin [LibreList] Re: [redecentralize] Check out Hiveware's decentralized platform (as in no servers) 2015-09-02 13:06:32
Moreover, as you must know, peer-to-peer systems work best when more people use it. If the Internet Protocol was covered by restrictive "intellectual property", we certainly wouldn't have this conversation. == hk -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJV5x6BXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0 ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9/b4QALCwk3sF24faV4DnjgpAI9wu 9Qs0H7vrtId7Z792gMUEciBwtIxZc7m7p/cojneUMcnIUq8qh6YMItd1rZC1WcKV arUrM/G8OReSpexYvt89tcUFHvBA8jHxXjNIoWscd4MBqeAWp/idirs3RkcDepdY bHHfVtjSOl2t5recnOlyZLMhCkzeZfOZtSgGM0jtkERUXuE8BQhqMqNxCQ6bNdhV Q4NsK59QHXGDlItdFD2PJkq57tu5C8kTkK9MaIxJwA0SF9bXMFVyZYCum+A7TvEU
Francis Irving [LibreList] Re: [redecentralize] Spring of User Experience 2014-03-05 10:55:24
need more crypto wrappers to provide usable APIs (good algorithms > default, sane use of RNG, etc) with clearly defined boundaries (embedding > the protocol's state machine instead of asking the developer to write it) > and good abstractions (the developer should not have to worry about > repeating
Geoffroy Couprie [LibreList] Re: [redecentralize] Spring of User Experience 2014-03-05 18:02:48
crypto wrappers to provide usable APIs (good algorithms > default, sane use of  RNG, etc) with clearly defined boundaries (embedding > the protocol's state machine instead of asking the developer to write it) > and good abstractions (the developer should not have to worry about > repeating
Robert Tischer [LibreList] RE: [redecentralize] Check out Hiveware's decentralized platform (as in no servers) 2015-09-02 13:49:55
Moreover, as you must know, peer-to-peer systems work best when more people use it. If the Internet Protocol was covered by restrictive "intellectual property", we certainly wouldn't have this conversation. == hk -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJV5x6BXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0 ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9/b4QALCwk3sF24faV4DnjgpAI9wu 9Qs0H7vrtId7Z792gMUEciBwtIxZc7m7p/cojneUMcnIUq8qh6YMItd1rZC1WcKV arUrM/G8OReSpexYvt89tcUFHvBA8jHxXjNIoWscd4MBqeAWp/idirs3RkcDepdY bHHfVtjSOl2t5recnOlyZLMhCkzeZfOZtSgGM0jtkERUXuE8BQhqMqNxCQ6bNdhV Q4NsK59QHXGDlItdFD2PJkq57tu5C8kTkK9MaIxJwA0SF9bXMFVyZYCum+A7TvEU
Jörg F. Wittenberger [LibreList] Re: [redecentralize] Applying User-Agent Behaviors in Web Applications to Enable Runtime Extension 2014-03-11 11:15:55
have to be a Citibank dev to dev Citibank. I'd need to research it more deeply, but I suspect that Askemos' protocols could be implemented in this extensions-architecture as a set of reltypes. It might be used to cluster multiple Worker scripts and remote services which all implement
juh [GG] Re: Redecentralize Radar, our super picky usable app directory 2017-02-28 23:20:00
centralization, because of the pace of development. All users like to have a fast development which improves the UX from release to release. Decentralized protocols are blockers for an agile development of services. I am not experienced enough to judge whether this is true. But it fosters my idea that
Johan Pouwelse [LibreList] Re: [redecentralize] The Shadow Internet: Please help us to get funding 2014-03-21 18:36:20
distributed database, such a wiki-style editing of metadata. We do not use the TOR network, we enhanced their protocol to make it compatible with our NAT puncturing techniques. Overview paper: http://sigmm.org/records/records1201/featured03.html About the merit of Bittorrent.. Our framework offers generic SOCKS5 interface, so other apps
Paul Frazee [LibreList] Re: [redecentralize] The Shadow Internet: Please help us to get funding 2014-03-21 13:41:47
distributed database, such a wiki-style editing of metadata. We do not use the TOR network, we enhanced their protocol to make it compatible with our NAT puncturing techniques. Overview paper: http://sigmm.org/records/records1201/featured03.html About the merit of Bittorrent.. Our framework offers generic SOCKS5 interface, so other apps can also
Ximin Luo [LibreList] Re: [redecentralize] The Shadow Internet: Please help us to get funding 2014-03-21 22:18:20
Bastien Guerry [LibreList] FLOSS4P2P: Call for Participation 2015-02-18 10:28:26
with a focus on distributed platforms. Scholarships to attend are offered to grassroots communities. ** Context ** We know that the Internet was originally decentralized, with protocols and services built by hackers. However, with the arrival of the celebrated Web 2.0, centralization and corporations proprietary platforms seem to have taken over. Moreover
Odinn Cyberguerrilla [LibreList] Net Neutrality Ruling, Internet Interprets Censorship as Damage, There are no Captains, Decentralize Everything, etc. 2014-01-14 12:14:11
upon laws, at least in my view. But it also made me think some more about this and realize that if we want decentralized protocols / solutions to spread at all, we have to do a way better job at being good advocates for them and talking about them incessantly
P S [LibreList] Tribler and Dispersy 2014-09-06 14:23:54
anyone used Tribler or reviewed the protocols and technical papers? https://github.com/Tribler/tribler/wiki
Jos Poortvliet [LibreList] connecting 2015-09-16 19:14:02
Benjamin ANDRE [LibreList] Re: [redecentralize] 2014-05-28 00:20:46
around your data (no silo). For now we lack social features, but we work on it with a techno called XDI (a format and protocol for semantic data interchange) wich is promoted by the startup Respect Network . We have a B2B2C business model, we have some promising clients (OVH, Orange
David Geib [LibreList] Re: [redecentralize] snow: a new distributed secure virtual network 2014-07-04 15:27:01
actually using HTTP, now your messaging app is vulnerable to XSRF for no good reason. Meanwhile they add kitchen sink support to the HTTP protocol in order to support all of this, increasing the attack surface dramatically. Meanwhile in order to do DPI against HTTPS the enterprise
Jörg F. Wittenberger [LibreList] Re: [redecentralize] Thoughts on decentralization: "I want to believe." 2014-08-03 14:21:03
schrieb "Jörg F. Wittenberger": Adam, I've got a question: … In this blog post you wrote: > I designed the protocol to be capable of evolving toward a more decentralized design in the future without disrupting existing users, but that's where it stands today
Adam Ierymenko [LibreList] Re: [redecentralize] Thoughts on decentralization: "I want to believe." 2014-08-04 16:04:39
sling packets is simply off the table, since it would kill battery life and eat up cellular data quotas. That basically eliminates every mesh protocol I know about, every DHT, etc. from consideration for mobile. >> In Turing-completeness there are shockingly minimal systems that are universal computers