reinstate help text, version

[dominictarr]

when we refactored everything, we (I mean I) removed help because sbot was managing it centrally and now it needs to be for each plugin.

#634
#647

but we should put that back...

[dominictarr]

@frankiebee found unexpected results for sbot version - it returned ssb-db's version not ssb-server's.
since ssb-server is moving to a distribution model i think version should really give the versions of all the plugins.

I realize that causes complications with: ssbc/secret-stack#36 (multiple versions in one .use(...) but maybe that is something we can fix? what do you think @staltz ?

Also, secret-stack actually allows a plugin without a name... it just becomes "core" so the methods provided by ssb-db such as createLogStream really maybe should be sbot db.createLogStream. Of course, changing that would break everything now (including legacy replication) but well, what we have currently isn't very good. Maybe we can move everything to db... but have a way to alias back to the old pattern.

[staltz]

@dominictarr Why would compound plugins in secret-stack affect this? .use(AB) is similar to .use(A) followed by .use(B), so it is still possible to call server.A.version and server.B.version.

[dominictarr]

@staltz the problem is that it if you did use(A) but really it was use([A,B,C]) and you do versions and get A,B,C you are gonna be confused... it's a leaky abstraction. (maybe we should just accept that though?) or should those versions be represented some way?

Oh, maybe when you load a bundle, each plugin should get a "parent" which points back to the bundle it came from. then the output can at least tell you what bundle it came in?

[staltz]

@dominictarr I'm still trying to understand, you think compound plugins need versions too?

[dominictarr]

@staltz yes I do. for example, ssb-server now doesn't do anything by it self - it's just a distribution of other things I guess it could be the thing which has the version? but I think knowing the version of each plugin would be very useful, and if something came with other things, I think that should be explicit too.

[staltz]

Ok, I think I understand.

One way to implement this is by changing secret-stack's support for arrays, and instead use an object {bundle: true, plugins: [A, B]} and instead of doing a Array.isArray check, we do if (plugin.bundle) check. I think no one is using array plugins yet, since we didn't release a new secret-stack version with that support, so I'm happy to do this "breaking change".

[jedahan]

It looks like the main (only?) difference between use([A, B]) and use(A).use(B) is making clear the intention that there is coupling between [A,B] in the former case, which seems good for helping understand what needs what. If that is the case, is there a way to support {name: 'whatever'} or {bundleName: 'someGroupOfPlugins'}, which would allow for version checking of both the bundle, or the individual plugins? (via server.someGroupOfPlugins.version and server.A.version). If I am missing context, feel free to lmk and I'll be quiet.

[dominictarr]

@jedahan yeah, I think some sort of pointer back to the bundle that loaded it would be enough to resolve any ambiguity. then you could do an output like

>sbot versions
{
  server: {
    gossip: v1, replicate: v2, ebt: v3, friends: v3, ...
  },
  oneOffPlugin: v4,
  anotherBundle: {
    ...
  }
}

imagine the vN is replaced with semver strings though...

[dominictarr]

I'm testing gitlo (github/trello integration) sorry everyone

[stale]

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

[gmarcos87]

Stale's robot closed this pull-request but in the documentation (ssb-db Readme.md) mentions it as something possible to be merged.

If it's definitely closed we can remove the mention in the Readme, otherwise it should open again.