* feat: Initial fname registry provider class
* flesh out fname registry provider functionality
* Update to match fip
* Use new query params and gradefully handle errors
* feat: add support for verifying username proofs
* Validate server signatures before submitting username proofs
* Add changeset and default fname server url
* rolling up changes for links FIP
* typeToSetPostfix
* pr feedback
* consistency to avoid js quirks
* add versioning logic and update tests
* include version check in mergeMessages
* update protobuf comment to reflect nit
* added changeset
* code coverage
This dependency is only required for dev, not production. It's used by
Hubble when generating fake data, however, so move it to a production
dependency for Hubble.
Fetch data in batches and execute jobs concurrently. This reduces the
time estimate from ~4 hours to under 1 hour on my machine.
We could probably make this even faster by implementing a
`getAllMessages` endpoint on the hubs.
Instead of requiring the user to run `yarn install` followed by `yarn
start`, we simply have them run `docker compose up` to start both the
app and Postgres together. This is much easier and reduces the need for
them to install anything else besides Docker. It also makes cleaning up
the example easier.
* feat: Suport sync status rpc call
* Add sync status hubble command
* Fix generated file
* Changeset
* Fix isSyncing check
* Rename to status and report db stats as well
* Fix error
We had a report of one user on modern MacBook with 16GB of memory who
was running into heap allocation issues. This was likely due to the
excessive number of promises we were creating (as well as buffering all
data for each call).
Change the logic to fetch in batches of 1K records at most. This slows
down the initial sync but should reduce the likelihood that someone will
hit a memory limit.
We also specify a custom limit in the `yarn start` command so that when
we test locally we are using the same limit as everyone else.
Provide a working end-to-end example of syncing data from hubs to a
Postgres database.
This should work with no additional dependencies besides what you
install with `yarn install` and Docker.
* feat: don't merge messages that would immediately be pruned
* Fix tests and minor cleanup/review comments
* Support all other stores
* Add changeset
* use prune iterator with keys available and expand cast store tests
* re-add prune iterator args
* Additional tests
* Add tests for other stores
---------
Co-authored-by: Sanjay Raveendran <sanjayprabhu@gmail.com>
* refactor: Rename sync events flag for clarity
* feat: Add sync statuts to HubInfo RPC call
* feat: Add sync stats to getInfo rpc call
* re-patch hub-web to use default export as before
* changeset
* support CastId embeds, url parents and reaction targets
* docs(changeset): support CastId embeds, cast parent URLs, and reaction target URLs
* fix validations test
* add version and embeds deprecated validation
* docs(changeset): upgrade to protocol version 2023.4.19
* update protobuf generated code
* add reaction service tests
* add more examples to builder tests
* add more cast and reaction tests
* upgrade hub-web in examples and move gossip to hubble
* use submitMessage for sync
* simplify logging in sync engine
* remove sync related methods from storage engine
* cleanup imports and remove test methods
* add changeset
* fix chron-feed example
* update chron-feed example
* intermediate commit
* add chron-feed hub-web example
* add changeset
* remove commented out imports from example
