Content pfp
Content
@
https://warpcast.com/~/channel/fc-devs
0 reply
0 recast
0 reaction
christopher pfp
christopher
@christopher
So open mental note here to not get clever and use the first 6 characters of a cast because it will collide.. i.e. 0xabcdef vs. 0xabcdef12 😔 Collision probability with 100,000 casts: - 6 characters: ~37% chance of at least one collision. - 8 characters: ~0.12% chance of at least one collision.
1 reply
0 recast
12 reactions
christopher pfp
christopher
@christopher
Don’t learn the hard way.
1 reply
0 recast
2 reactions
artlu 🎩 pfp
artlu 🎩
@artlu
isn't the idea that the username is part of the shorthash?
2 replies
0 recast
0 reaction
Andrei O. pfp
Andrei O.
@andrei0x309
No, username is not part of the hash but is part of the query. They use both the username and short hash, which practically forms a composite key with improbable collision. They could use the full hash as @christopher says, also a composite key can be faster, but not in all scenarios. It can also be slower depending on DB and implementation, and it also might require additional storage with little benefit. What I think is the real reason is that they wanted to have a nice URL, that doesn't contain the hash in full form. Again without full source code, everything related to the client is speculation.
1 reply
0 recast
1 reaction
christopher pfp
christopher
@christopher
Hmmm not sure if username is part of the query because usernames do change over time. But fid could/should be. cc @cmlad.eth @sds
1 reply
0 recast
1 reaction
Andrei O. pfp
Andrei O.
@andrei0x309
That's what the REST endpoint that Warpcast uses suggests: ``` getCastThread = async ({ castHash, limit = 15, username, cursor = '' }: { castHash: string, username: string, limit: number, cursor?: string }) => { const response = await fetch(`${this._apiEndpointBase}/user-thread-casts?castHashPrefix=${castHash}&username=${username}&limit=${limit}${cursor ? `&cursor=${cursor}` : ''}`, { method: 'GET', headers: this.headers }); return await response.json() as TWcUserThreadItems } ``` The username may change true but when it does the change will also be picked up and and probably synced with the DB. Now we don't know how the username and hash prefixed are used on the backend(since is not open) but those are used at least in the REST query if not in the DB query.
1 reply
0 recast
2 reactions
christopher pfp
christopher
@christopher
Oh yeah that is my conclusion. Uno uses the hash and gets fine performance in Postgres on the backend. My guess is the query key is probably for frontend URL params lookup performance and invalidate the cache if it drifts.
2 replies
0 recast
2 reactions
christopher pfp
christopher
@christopher
In my older casts quoting Erica, they’re all broken because she used her old username to cast them.
0 reply
0 recast
2 reactions
Andrei O. pfp
Andrei O.
@andrei0x309
I mean if you build your own indexer, you can make your own strategies, there were a few apps before that had their own indexers, but now most clients are purely based on what Naynar provides. But the Warpcast client evidently has its own indexer, which is not based on Naynar calls, albeit you can also create a custom indexer using Neynar events. The only close to native way was with listening to Hubs, and will also be with Snapchat, but to be honest there are no docs on that, I am very curios if with Snapchain there will be any public read/write nodes without publicly accessible nodes, this network would be super closed and will have its value furthermore diminished. Using a full hash as an index should be a great strategy, for most databases, I did work with an indexer in both Mongo and Postgresql, and the full hash was used internally though the frontend used a UUID that was tied to a copy of the post.
0 reply
0 recast
0 reaction