Varun Srinivasan pfp
Varun Srinivasan
@v
Should Farcaster count string lengths as bytes or characters? https://hackmd.io/@farcasterxyz/BJeFoxdy3
15 replies
0 recast
0 reaction
Varun Srinivasan pfp
Varun Srinivasan
@v
Thanks everyone! A tough decision, but we made the final call after factoring in everyones feedback today: https://hackmd.io/@farcasterxyz/BJeFoxdy3
0 reply
0 recast
0 reaction
Corbin Page 👑🎩 pfp
Corbin Page 👑🎩
@corbin.eth
Option B imho
1 reply
0 recast
0 reaction
Cameron Armstrong pfp
Cameron Armstrong
@cameron
B - TIL why I get so confused when I can’t predict how long my casts and replies are allowed to be
1 reply
0 recast
0 reaction
blingbling🌟 pfp
blingbling🌟
@16
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.
1 reply
0 recast
0 reaction
Daniel Lombraña pfp
Daniel Lombraña
@teleyinex.eth
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.
1 reply
0 recast
0 reaction
cj pfp
cj
@cj
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?
1 reply
0 recast
0 reaction
Greg pfp
Greg
@greg
Option A feels too technical for most users
0 reply
0 recast
0 reaction
Connor McCormick ~ jtrending pfp
Connor McCormick ~ jtrending
@nor
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
0 reply
0 recast
0 reaction
blobs pfp
blobs
@blobs
A for protocol can’t B just be enforced arbitrarily inside a client SDK like farcaster-{js,py,…} that all the client implementers use?
0 reply
0 recast
0 reaction
Alex Loukissas 🍉 pfp
Alex Loukissas 🍉
@futureartist
For users: characters. Unicode (and multibyte characters specifically) are too much of an implementation detail
0 reply
0 recast
0 reaction
Rohit Kulshreshtha pfp
Rohit Kulshreshtha
@rohit
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.
0 reply
0 recast
0 reaction
dimalaba.eth pfp
dimalaba.eth
@dimalaba.eth
A - better to be technical and precise for protocol (+ others use bytes) B,C can be implemented at client level
0 reply
0 recast
0 reaction
Omar Mezenner pfp
Omar Mezenner
@omeze
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
0 reply
0 recast
0 reaction
Jackson 🎩🍖🐈‍⬛ pfp
Jackson 🎩🍖🐈‍⬛
@jacks0n
A seems better for protocol design, B seems better for UX
0 reply
0 recast
0 reaction
Josh Babetski pfp
Josh Babetski
@quixado
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.
2 replies
0 recast
0 reaction