Advanced
Varun Srinivasan@v
3/10/2023

Should Farcaster count string lengths as bytes or characters? https://hackmd.io/@farcasterxyz/BJeFoxdy3

In reply to @v
Corbin Page@corbpage
3/10/2023

Option B imho

In reply to @v
Jackson@jacks0n
3/10/2023

A seems better for protocol design, B seems better for UX

In reply to @v
Cameron Armstrong@cameron
3/10/2023

B - TIL why I get so confused when I can’t predict how long my casts and replies are allowed to be

In reply to @v
Greg Skriloff@greg
3/10/2023

Option A feels too technical for most users

In reply to @v
16@16
3/10/2023

B: Regardless of the tool, it is humans who ultimately using them. Therefore, it's important choose a more user-friendly approach, one that is more attuned to our human nature.

In reply to @v
Connor McCormick@nor
3/10/2023

A Famously, twitter increased its character count because they were treating Japanese characters as 1 even though they were many bytes & had more information than the average English word. Because of this, Japanese Twitter had healthier "dynamics", because there was more information per tweet. A fixes this discrepancy

In reply to @v
Tom Winzig@tomwinzig
3/10/2023

The protocol should do it based on bytes; the clients should do it based on characters (i.e. conveying to the user how much more they can type is a UX issue for clients to solve on their own).

In reply to @v
blobs@blobs
3/10/2023

A for protocol can’t B just be enforced arbitrarily inside a client SDK like farcaster-{js,py,…} that all the client implementers use?

In reply to @v
Alex Loukissas@futureartist
3/10/2023

For users: characters. Unicode (and multibyte characters specifically) are too much of an implementation detail

In reply to @v
Rohit Kulshreshtha@rohit
3/10/2023

A If the protocol is shardable down to fid, the information content of a fixed number of casts is an individual level concern rather than a protocol concern.

In reply to @v
Daniel Lombraña@teleyinex
3/10/2023

Lens has no limits. Would like to know why the protocol decided to set a limit. Regarding the question: I would choose what's best for the protocol. Then the client libraries should abstract this issue for the devs.

In reply to @v
dimalaba.eth@dmlb
3/10/2023

A - better to be technical and precise for protocol (+ others use bytes) B,C can be implemented at client level

In reply to @v
cj@cj
3/10/2023

Can casts be “composed”? Say cyrillic, I want 320 actual symbols. Can I compose two casts of 160 symbols (320 bytes) to create a single one of 320 symbols? Is this up to client implementation?

In reply to @v
Omar Mezenner@omeze
3/10/2023

100% characters since that's what normal people deal with. 'characters' are a little ambiguous but I like Go's definition of 'runes', which is really just a unicode code point: https://go.dev/blog/strings

In reply to @v
Josh Babetski@quixado
3/10/2023

Option B + some C + the remaining char. counter from A. B: Concur with the build for humans replies. Hot take is also the "half as many messages" argument may be a bit fallacious. Not every cast will max out, people maxing out will just thread and post multiple casts, so you're down to people abbr 2 fit w/i char lmts.

In reply to @v
Varun Srinivasan@v
3/11/2023

Thanks everyone! A tough decision, but we made the final call after factoring in everyones feedback today: https://hackmd.io/@farcasterxyz/BJeFoxdy3