Browser ipfs-http-client not replicating pubsub from kubo daemon.

[threshold862543]

• Version:
  Object { version: "0.14.0", commit: "", repo: "12", system: "amd64/linux", golang: "go1.18.3", "ipfs-http-client": "1.0.0" }

• Platform:
  64 bit Ubuntu. Firefox 102.0.1.

Severity:

High - The main functionality of the application does not work, API breakage, repo format breakage, etc.

Description:

I am running a kubo ipfs daemon on a given machine. I'm using ipfs-http-client (version 57.0.0) on a Node.js application server on the same machine to write entries to a database. If I connect other ipfs-http-clients running on on the same node server (different multithreaded processes), I am able to retrieve the oplog and build the index of database entries. However, when I try to use a browserified bundle (version 56.0.0 due to bundling issues with later versions) and run the ipfs-http-client in the browser, I am able to open the database, but the oplog returns as empty. It seems like something about the browser environment is preventing pubsub/the oplog from functioning properly, whereas the same general setup with Node.js worked as expected (each ipfs-http-client instance and orbitdb instance was able to maintain it's own synced copy of the database).

Steps to reproduce the error:

• Run kubo ipfs daemon.
• Connect to it on localhost with ipfs-http-client and orbitdb client on a Node.js server process A.
• Repeat the above step on another process B for verification.
• Create oplog entry by eg. put() a document via client A.
• get('') the database from client B and observe that the entry is replicated.
• Build a browser bundle with ipfs-http-client and orbit-db using browserify.
• Instantiate browser client C and open the database.
• get('') the database via client C and observe that it is not replicated.

[welcome]

Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review.
In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We currently aim to give initial feedback within two business days. If this does not happen, feel free to leave a comment.
Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers:

• "Priority" labels will show how urgent this is for the team.
• "Status" labels will show if this is ready to be worked on, blocked, or in progress.
• "Need" labels will indicate if additional input or analysis is required.

Finally, remember to use https://discuss.ipfs.io if you just need general support.