Live data from Hacker News

Hello (Distributed) World: Designing Software that Spreads P2P

blog.cyll.org

1–10 of 32 posts

Re: Hello (Distributed) World: Designing Software that Spreads P2P

#8
post #3

it's a little annoying hearing about but not seeing this "spin" language.

Here's some basic syntax.

  values = '[1, 2, 3]
  incremented = values.map({ n | n + 1 })
  summary = incremented.join(", ")

  summary.starts-with?("1").then({
    fail("Increment failed.")
  })

Re: Hello (Distributed) World: Designing Software that Spreads P2P

#9
post #6

Earlier quoted context omitted.

What sort of examples would you be most interested in seeing?

How about a chatroom?

Ignoring user interface and the mechanics of peer discovery...

  user-interface, discovery-system |
  # This process is spawned with two pids as arguments
  
  # If either pid halts, I halt too.
  user-interface.link
  discovery-system.link
  
  user-interface.subscribe(when(
    text-entered: { message |
      # I entered a message in the UI, announce it to everyone subscribed to me
      my-actor.announce('exclaimed, message)
    }
  ))
  
  discovery-system.subscribe(when(
    peer-discovered: { name, peer |
      # Discovery system located another user in the chat room
  
      # Send message to user-interface showing a Growl style notification.
      user-interface 

Re: Hello (Distributed) World: Designing Software that Spreads P2P

#10
post #5

Interesting. But what is their approach to security? Capability-based? Or simply not connecting to computers you don't trust?

Generally speaking, we don't connect directly to unknown computers, but there are other reasons for that.

Security is addressed at a few levels (here are 6 of them).

1. Access to native resources requires specific permission.

2. All processes (including those with access to native resources) can only be addressed by their 288-bit process identifier (128-bits of which are random). The only identifiers known to a process are its own, those of its children, and ones explicitly given to it.

3. The Actor model means each process can independently decide which messages to reply to, which to ignore, and how long to wait for a response (if at all).

4. Each node has a unique RSA key-pair. The 160-bit fingerprint of the public key is the non-random part of every process identifier. This allows nodes to verify the remote processes they communicate with. (And if necessary, encrypt messages sent to them.)

5. Hash-based distribution makes it easy to blacklist poorly-written or maliciously-crafted code, once it's been identified as such.

6. System services in Skynet are always kept current with live, on-the-fly updates.

Post reply on HN