* chore: changelog bump to app/hubble to prep for release
* chore: don't minor bump hubble and protobufs for client changes
* chore: bump versions for publishing
Using `fs.watch` uses `inotify`, which doesn't work with network file
systems like EFS where other kernels could be responsible for changes to
the file system.
Instead, check every 10 seconds to see if there is a change.
Ran this locally and it seemed to work fine.
* chore: update all devDependencies to the latest versions
* chore: update @noble/hashes to 1.3.0
* chore: update @swc/core to 1.3.41
* chore: update @noble/ed25519 by a patch version
* chore: update ts-proto and eslint/parser dev deps
* chore: upgrade pino minor version
* chore: upgrade tsx minor version
* chore: add changeset
* poc
* address pr feedback, add pagination to getAllSignerMessagesByFid
* fix types
* use bytes and uint32
* move makeEndPrefix into utils
* getSignersByFid
* fix: getCastsByFid should return items in reverse chronological order
* returns casts in chronological order
* fix: getCastsByFid should return casts in chronological order
In the RocksDB iterator we use to construct thashes for the messages query, select only the CastMessages which are CastAdds
* rename page options and move page iterator to message file
* intermediate commit
* fix tests
* use suffixes as tokens rather than full keys
* remove commented out code
* paginate getCastsByParent, getCastsByMention, getReactionsByCast
* add changeset and fix linting
* update multiPeerSyncEngine test
* add more tests
* fix import
---------
Co-authored-by: bstchow <36556453+bstchow@users.noreply.github.com>
Co-authored-by: Paul Fletcher-Hill <pfletcherhill@gmail.com>
We want to know exactly how many bytes we're storing. Check using utf8
byte length instead of character length.
This also requires changes to our mentions validations, since we now
need to check in terms of bytes instead of characters.
While here, based on team discussion and current cast data, increase
maximum number of mentions from 5 to 10.
* add: SignerAdd and SignerRemove to message.proto
* add: finish message.proto and validations
* progress: refactor signer factory
* update tests to support signerAddBody and signerRemoveBody
* add changeset
---------
Co-authored-by: Paul Fletcher-Hill <pfletcherhill@gmail.com>
It is possible for a cast to have multiple mentions with the same
position. Consider the following cast:
@a@b@c
In this case, we are mentioning the users `a`, `b`, and `c`, without
separating their names with any other text. The resulting
`mentionsPositions` will be `[0, 0, 0]`, since there is no change in
position.
Relax our validations to allow this case.
* Allow empty cast text
Since a cast could consist of just a mention, a valid cast can have no
actual text, only a mention.
We should not fail in this case.
* Create silly-trees-tickle.md
---------
Co-authored-by: Paul Fletcher-Hill <1607180+pfletcherhill@users.noreply.github.com>
