# gossip-query

> flooding gossip search for p2p.

Latest version **2.0.2** (published 2019-02-10) · MIT license · 0 weekly downloads

## Install

```sh
npm install gossip-query
pnpm add gossip-query
yarn add gossip-query
bun add gossip-query
```

## Health

**Score 15/100 (F)** — status: abandoned.

Positive: no vulnerabilities.

Warnings: low downloads; no types; no esm support.

Negative: abandoned; low maintenance score.

## Facts

| | |
|---|---|
| Version | 2.0.2 |
| Published | 2019-02-10 |
| First published | 2017-10-20 |
| Weekly downloads | 0 |
| License | MIT |
| TypeScript types | none |
| Module format | CommonJS |
| Dependencies | 2 |
| Unpacked size | 169.6 KB |
| Known vulnerabilities | 0 |
| Install scripts | no |
| GitHub stars | 11 |
| Author | 'Dominic Tarr' |
| Maintainers | autonomous, bschulzsf, cel, dominictarr, juul |

## Links

- npm: https://www.npmjs.com/package/gossip-query
- Repository: https://github.com/dominictarr/gossip-query
- Issues: https://github.com/dominictarr/gossip-query/issues
- npm.io page: https://npm.io/package/gossip-query

## Dependencies (2)

- [obv](https://npm.io/package/obv.md) 0.0.1
- [pull-stream](https://npm.io/package/pull-stream.md) ^3.6.0

## Recent versions

- 2.0.2 (latest) — 2019-02-10
- 2.0.1 — 2019-02-10
- 2.0.0 — 2019-02-10
- 0.2.3 — 2018-10-29
- 1.1.0 — 2018-03-11
- 1.0.0 — 2017-11-16
- 0.2.2 — 2017-11-13
- 0.2.1 — 2017-11-12
- 0.2.0 — 2017-11-12
- 0.1.0 — 2017-11-12
- 0.0.1 — 2017-11-09
- 0.0.0 — 2017-10-20

## README

# gossip-query

flooding gossip search for p2p.

## pseudocode

```
something is requested (either by local user, or a peer)
check for it locally (async),
  if you have it
    respond to peers who requested it
  else
    ask other peers
    if a peer responds
      check it's correct
      then respond to any peers who requested it
```
> note: "peers who requested" can be the local user or a remote peer.
  if a second request is made for queries already in the system,
  the requestor is just added to the waiting callbacks, instead of starting
  that request over.

when two peers connect, they exchange a table of the things they
are looking for. when a request is made on behave of a peer,
a hops counter is incremented. That way, a who may be several
steps on from the source can see how far it has come, and may
choose to ignore distant requests.

## protocol

requests are sent in the form of a JSON object, with the query string
as the key
{<query>: <hops> || <response>,...}

the <query> can be anything, it's just a way to identify that request.

more than one request/response can be broadcast in a single packet.
normally, `<hops>` is a negative integer
(but could be some other representation
of the weighting of how important the request is, as long as it's distinct
from any value of `<response>`)
`<response>` can be any value, and in some cases it allows only one value,
for example,
in ssb-blobs the request is the blob hash, and the response
is the size of the blob.
in a search query, the request would be the query string,
and the result is responses (which might be message ids or something like that)

for [ssb-ooo](http://github.com/ssbc/ssb-ooo) (out of order messages),
the response is just the message, and there
can never be more than one result.

for protocols that can have multiple responses, a reduce function is supplied
that combines those results.

## data structure

the state of the protocol is represented as a {} object of the state
of each request.

```
{<query>: <state>,...}
```
`state` holds information about what phase this query is in,
this contains a list of peers (can include the local user) who have
made a particular query, (and that the response will be transmitted to,
once received) it contains the value received (if we have it)

requested values should be cached for some length of time, but eventually
gc'd (maybe combining a count and a time limit)

> i'm not completely clear on what the state object needs to look like
  it might need a map of which peers have requested and which peers have
  been sent data.

## pull based

to make the protocol properly pullish (and respect back pressure)
i think the right idea is that when a peer is ready for data,
iterate over the state objects and check which have data for them,
this way it can just wait as long as necessary if the peer doesn't
want anything yet.

## processing

the processing step, (after a response is received from a peer)
is optional - but in the case of ssb-blobs would be used to request
that blob from the peer.

## License

MIT

---
_Source: https://npm.io/package/gossip-query · Machine-readable twin of the npm.io package page. Health data is recomputed on every publish._