Improving Documentation

[gmarcos87]

I want to update the ssb-config but I found some doubts with some values of the configuration.
The options I would like more information about are:

• config.remote
• host in the connection>transport

These options I could not find where they are used, maybe they are deprecated or I did not search well

• config.timers.connection
• config.timers.reconnect

I also added the options for ssb-party, timers.keepalive and timers.inactivity

---

Maintenance Grant (%dka5LyifpeWotdE1LxNGmbk1Jtwme0RUlA0LhfM0blQ=.sha256)

[cryptix]

config.remote is used by ssb-client to make its server connection. It needs to be a multiserver address.

[cryptix]

host in connection should define an IP or hostname that the listener is binding on, IIRC.

[gmarcos87]

config.remote is used by ssb-client to make its server connection. It needs to be a multiserver address.

• remote(string) Multiserver address to connect as a remote client (see ssb-client)

  @cryptix Is that right?

[mixmix]

I think the remote thing gets used if it's present, otherwise it gets constructed from some of the other info (this is a vague memory). It's most useful in the case of using ssb-unix-socket + 'ssb-no-auth. Here's an example piece of config used by patchbay (via ssb-ahoy) for example:

    {
      connections: {
        incoming: { unix: [{ scope: 'device', transform: 'noauth', server: true }] }
      },
      remote: `unix:${join(config.path, 'socket')}:~noauth:${pubkey}` // overwrites
    }

this is a kinda advanced use case but is a really nice feature for unix-based systems

[mixmix]

might be good to specifiy that local means "on the same local network as you"

[mixmix]

I think these settings need more clarification.
Like if you set global: true, then does that over-ride local: false? your description here suggests that. I think this is more about making connections with people not on the local network. ... but then I don't know what that "friends" option is about...

[gmarcos87]

Okay, so I made some changes in relation to gossip. I had to read the code to see how the settings affected performance.
I also changed the information about remote, but I still have doubts with the timers, I can't find any code that uses timers.connections and timers.reconnect

[victorb]

Not sure if this is the right place to mention this (but it has bitten me before), when entering the public key in the multiserver address, you need to make sure you don't have the public key type in there, as otherwise ssb-client will fail with cryptic errors. Most probably a bug, but until it gets fixed, might be good to mention here.

So, the multiserver address has to be something like ws://127.0.0.1:8989~shs:@FlzOOyrhTG+Cl6YND5tReJtd2ufUj3++F0ZsfcPalRc= (missing .ed25519 that seems to be optional in all other places but in a multiserver address)

[gmarcos87]

Good catch @victorb, I added the link to the definition of multiserver address.
The address you were trying (with the key type at the end) is not considered a valid address.

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

[arj03]

Anything stopping this from being merged? @gmarcos87

[mixmix]

Time to review it! If you recommend it, then that's enough for you to merge + publish a new version ?

…

On Aug 3 2020, at 7:40 pm, Anders Rune Jensen ***@***.***> wrote: Anything stopping this from being merged? — You are receiving this because you commented. Reply to this email directly, view it on GitHub (#70 (comment)), or unsubscribe (https://github.com/notifications/unsubscribe-auth/AAUK3HRUEIZ7OL4F6Z6TQD3R6ZSYTANCNFSM4KIIDHQA).

[arj03]

Alright, did a review and the changes looks good to me. I have made another commit with some minor changes after the merge as this branch was not in this repo.