You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Find all uses of direct sbot access in packages #104
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.
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.
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".
Activity
soapdog commentedon Jul 14, 2021
searching for
sbot.in thesrc/packages/folder found 121 files accessing it directly... oh boi, this will be a huge task.cryptix commentedon Jul 14, 2021
@Happy0 did something very similar with his chess app to make it work in browser/db2. Maybe you should compare some notes? :)
[[ ssb ]] refactored `ssb.sbot.id` to `ssb.feed`.
[[ system ]] Refactored to use `ssb.system.acceptInvite`
[[ system ]] refactored to use `ssb.system.*`
soapdog commentedon Jul 14, 2021
Only 17 matches left. They are all pipelines using pull streams.
soapdog commentedon Jul 14, 2021
🔥 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.
[[ blog ]] refactored to use `ssb.addBlob`
[[ post ]] refactored to use `ssb.addBlob`
[[ books ]] removed direct sbot access, fixed bug with cover
[[ contacts ]] refactored to `ssb.addBlob`
[[ contacts ]] removing direct access to `sbot.links`.
soapdog commentedon Jul 14, 2021
The remaining four files using
sbotdirectly are doing it in pull stream pipelines that are bespoke to their needs. I don't feel we should abstract them into some function inssb.*, 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.[[ ssb ]] rename `platforms/ssb` to `platforms/nodejs-ssb`
[[ zine ]] detect `nodejs-ssb`
[[ contacts ]] detect `nodejs-ssb`
[[ calendar ]] detect `nodejs-ssb`
soapdog commentedon Jul 22, 2021
The packages making direct pull-stream calls are:
scuttle-bookwhich 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.ssb.serverType === "nodejs-ssb".ssb.serverType === "nodejs-ssb".MoreInfomessages. It is already wrapped inssb.serverType === "nodejs-ssb".soapdog commentedon Jan 11, 2022
I suspect this is done.