Skip to content

Find all uses of direct sbot access in packages #104

Closed

Description

@soapdog

To support multiple server implementations, packages should preferably use the ssb.* high-level APIs instead of direct ssb.sbot.* access because the later can end up providing an API that is only present on a single server implementation.

To better understand the refactoring needs to remove direct sbot access, we need to find out where this access happens.

  • find all packages that access sbot directly.
  • find all packages that use some NPM dependency that access sbot directly.

Activity

  1. self-assigned this
    on May 27, 2021
  2. soapdog commented on Jul 14, 2021

    @soapdog
    OwnerAuthor

    searching for sbot. in the src/packages/ folder found 121 files accessing it directly... oh boi, this will be a huge task.

  3. cryptix commented on Jul 14, 2021

    @cryptix

    @Happy0 did something very similar with his chess app to make it work in browser/db2. Maybe you should compare some notes? :)

  4. soapdog commented on Jul 14, 2021

    @soapdog
    OwnerAuthor

    Only 17 matches left. They are all pipelines using pull streams.

  5. added
    tier-1top priority
    and removed
    tier-2secondary priority
    on Jul 14, 2021
  6. soapdog commented on Jul 14, 2021

    @soapdog
    OwnerAuthor

    🔥 This issue is on FAYAH! 🔥

    Almost done with removing direct sbot usage from packages. This is the first step in allowing Patchfox to work with other backends.

  7. soapdog commented on Jul 14, 2021

    @soapdog
    OwnerAuthor

    The remaining four files using sbot directly are doing it in pull stream pipelines that are bespoke to their needs. I don't feel we should abstract them into some function in ssb.*, instead the plan will be implementing #106 and provide a mechanism for package developers to detect and branch their code depending on what kind of backend is running.

  8. soapdog commented on Jul 22, 2021

    @soapdog
    OwnerAuthor

    The packages making direct pull-stream calls are:

    • Books
      • A bit trickier since not only it uses a direct call to pull-streams, but it also uses scuttle-book which might not be compatible with ssb-db2 or go-ssb. Probably will need to disable that package for the other platforms until I'm sure how to proceed.
    • Calendar
      • Uses it for exporting to ICS and timeline view. Both are already wrapped in ssb.serverType === "nodejs-ssb".
    • Zine
      • Uses pull-streams to get subscribed channels and the content for a given channel. Both wrapped with ssb.serverType === "nodejs-ssb".
    • Contacts
      • Uses it for MoreInfo messages. It is already wrapped in ssb.serverType === "nodejs-ssb".
  9. soapdog commented on Jan 11, 2022

    @soapdog
    OwnerAuthor

    I suspect this is done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

help wantedExtra attention is neededtier-1top priority

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions