I'm trying out how discovery.leave works, but failed.

Computer A is the writer:

var hypercore = require('hypercore')
var discovery = require('hyperdiscovery')

var feed = hypercore('./data', {valueEncoding: 'utf-8'})

feed.on('ready', () => {
  var sw = discovery()
  feed.append('\ncool')
  sw.add(feed)
  sw.leave(feed.discoveryKey.toString('hex'))
})

Computer B replicate the archive:

var hypercore = require('hypercore')
var discovery = require('hyperdiscovery')

var feed = hypercore(
  './data',
  '2e7be17277e5b0799408fd022038d5ca1a3586df88db8dc3e736b5977f1a52e9',
  {
    valueEncoding: 'utf-8'
  }
)

feed.on('ready', () => {
  var sw = discovery()
  sw.add(feed)
})

I expect that after sw.leave(feed.discoveryKey.toString('hex')) executed on computer A, data 'cool' will not be replicated to Computer B. But replication still happened.

So, if there're some more examples will be help.

@DeltaF1 had an issue using the Dat SDK in two processes. RangerMauve/hyper-sdk#8

It would throw a Error: Could not bind exception on the UTP socket.

xtend can easily be replaced with Object.assign

This reduce the dependencies and possible also avoid duplicated versions where some package don't use the same version range for the xtend package

// immutable
Object.assign({}, a, b)

// mutable
Object.assign(a, b)

I'm going through all of the hyper*universe and noticed that hypervision creates its swarms like hyperdiscovery(feed, {live: true}), where feed is a hypercore.

Currently the readme is lacking the live option, so I'm not entirely sure what it does; feels like it might let peers know that a feed is creating new data in realtime?

I have a pretty simple example running with hypercore that allows peers to connect. All peers can read just fine (including live). But it seems as though the only peer who can write to the feed is the original (the one that generated the key). Is this correct? How do I enable two-way replication using hypercore (so that all clients end up with all the data)?

I think it'd be cool to integrate discovery-swarm-web in the browser field so that people can compile hyperdiscovery to work on the web.

I think it'd be a good idea to move this to the dat project blog to make discoverability easier and to keep more Dat-related stuff in one place.

Closing the connection isn't the same behavior as discovery swarm. I think it might be nice to keep the api consistent, there are use cases where you want to stop announcing but still keep connections open. 'close' or "destroy" can be the thing that kills the connections as well as stops announcing.

We could use close/destroy but would need to have an API for destroing single feed vs the whole swarm.

How to replicate hypercore, like discovery-swarm

feed.ready(function () {
  // we use the discovery as the topic
  swarm.join(feed.discoveryKey)
  swarm.on('connection', function (connection) {
    console.log('(New peer connected!)')

    // We use the pump module instead of stream.pipe(otherStream)
    // as it does stream error handling, so we do not have to do that
    // manually.

    // See below for more detail on how this work.
    pump(connection, feed.replicate({ live: true }), connection)
  })
})

When the hyperdiscovery have be created ,how to connect it pass dat-node app?

The dat CLI is currently using discovery-swarm, which attempts to connect over a dht (which fails) but also opportunistically tries mdns and dns. Hyperswarm introduces a new DHT which we want to integrate here to replace the DHT that isn't working. Hyperswarm also has holepunching!! This will be great for the CLI.

What do you think about retiring discovery-swarm/channel completely and using as much of hyperswarm as possible, but also adding support for mdns and dns-discovery in this repository. Then we can use this repository in the dat v2 CLI.

Option 2 would be to update the discovery code in hyperswarm/discovery so that it also tries mdns and dns. Then this hyperdiscovery repository would not be needed and could be retired.

Thoughts, @RangerMauve @mafintosh @andrewosh ?

discovery.totalConnections return the length of the list of total active connections not list itself.

I want to store the port option in a database for dat-node so we can reuse whatever port worked last. But I think we need some way to make listen & join async. Maybe opts.autoListen or something (default: true), would be a way to do this? Or any other more straightforward suggestions?

Sudo code implementation in dat-node:

// Check for existing port saved
// PROBLEM: Happens async
if (opts.port && db) {
    var subDb = sub(db, `${encoding.toStr(archive.discoveryKey)}-network`)
    subDb.get('port', function (err, val) {
      if (err && !err.notFound) throw new Error(err)
      if (val) opts.port = val
      doListen()
    })
}

// Happens sync
opts.autoListen = false
var swarm = hyperdiscovery(archive, opts)


// ... later with `autoListen = false`

function doListen () {
  swarm.once('error', function () {
    swarm.listen(0)
  })
  swarm.listen(opts.port)
  swarm.join(this.archive.discoveryKey)
  swarm.once('listening', function () {
    subDb.put('port', swarm.port) // save whatever port succeeded
  })
}

We could make the whole network function async in dat-node too. Maybe that is the easier solution but the rest of the networking APIs are sync.

Hello! I'm new and just getting started here...

When attaching to an existing swarm and trying to write to a hyperdrive, I get the error This feed is not writable. Did you create it?. Are there some settings to allow a newly connected peer to write to the shared "disk"?

Thanks!

running the tests on 9.0.2, got double free or corruption (!prev)

not all the time, just sometimes.

“Run the following code in two different places and they will replicate the contents of the given ARCHIVE_KEY”
How to get the ARCHIVE_KEY?