You are reading content from Scuttlebutt
@cryptix %5URTnw/M8nzo6aD0Jy2ybgahkegqKYt56DQWFNN6ULo=.sha256
Re: %1ts45jTyl

Lastl, I did a comparison of the JS test suite with what I did. @arj helped me to fill in some of the blanks

comparison of the JS test suite

  • binary.js - a test for encoding binary data instead of json blobs
    not supported at all yet and thus not tested.
    needs support for encoding messages by type/sign algo.

  • block.js - not sending messages to blocked peers
    not tested yet.
    though, blocked peers shouldn't end up on the feed want list.

  • chain.js - three peers connected in series
    translates to sbot/feed_live_test.go where this is done with chains of 2,3 and 5.

  • live-stall.js - network of 4 peers and one of them stops after a couple of ticks
    not yet tested but should be easy to do with feed_live

  • multiple.js - if connects to multiple peers, should replicate a feed from only one
    not yet implemented, thus not tested

  • timeout.js - tests similar behavior as multiple AFAICT
    not yet implemented, thus not tested

  • simple.js - connect two peers and sync 3 messages
    covered by sbot/feed_*

  • two.js / three.js - connect a couple of peers in series
    coverd by sbot/feed_live_test.go

  • fork.js - bob has a forked version of alices feed, should disable rx

  • client.js - when sends their note first, client or server?
    I slightly misunderstood the protocol first. I thought it was just important which side starts the duplex stream and then each send their notes/vector clock.
    But it's a bit more intricate, as highlighted by the comments in this github discussion

The biggest outstanding issue is fork detection and stopping to receive those feeds.

Join Scuttlebutt now