fc.proto
/fc-proto51
Unofficial space to discuss, debate and share ideas about the low level aspects of the Farcaster protocol. Low volume, few members, personal bias on who can join. DC @vrypan with a link to your FIP comments, and who knows.
Farcaster provides a well-defined namespace, which (thanks to global state) it is very easy to resolve.
For example, the following paths are clearly defined, once we know that we are using the Farcaster namespace.
- vrypan/pfp
- vrypan/url
- vrypan/cast/0x....
- vrypan/location (soon :-)
How can we expose this namespace to the rest of the world? A great example is furl.pro that bridges the fc namespace to http. Can we create a standard? Can we build some type of infrastructure (thinking a farcaster DNS for example, or an ENS, or maybe something else) others protocols/apps can use?
Share ideas!
For example, the following paths are clearly defined, once we know that we are using the Farcaster namespace.
- vrypan/pfp
- vrypan/url
- vrypan/cast/0x....
- vrypan/location (soon :-)
How can we expose this namespace to the rest of the world? A great example is furl.pro that bridges the fc namespace to http. Can we create a standard? Can we build some type of infrastructure (thinking a farcaster DNS for example, or an ENS, or maybe something else) others protocols/apps can use?
Share ideas!
It is always very educational to read @vitalik.eth's thoughts on these things.
I'm trying to see what we can learn and use in the upcoming Farcaster chain. One interesting point is that the the three competing goals do not apply to Farcaster, because time to finality is not something to optimize for.
On the other hand, it seems that we have accepted that we should not try to maximizing the number of validators, which I'm not comfortable with, and we are mostly focused on efficiency.
I'm trying to see what we can learn and use in the upcoming Farcaster chain. One interesting point is that the the three competing goals do not apply to Farcaster, because time to finality is not something to optimize for.
On the other hand, it seems that we have accepted that we should not try to maximizing the number of validators, which I'm not comfortable with, and we are mostly focused on efficiency.
Broad vs Narrow data types (for example, cast location vs external data FIPs)
I'm in favor of broad types. I like how RSS enclosures allowed podcasting to emerge (and practically this is the only broadly used RSS application today). Broad types allow clients to implement new features without protocol updates -more permissionless from a dev pov.
On the other hand, narrow types create a well-defined, well-scoped environment, easier to navigate for devs who want to implement a standard feature set.
What's your take?
I'm in favor of broad types. I like how RSS enclosures allowed podcasting to emerge (and practically this is the only broadly used RSS application today). Broad types allow clients to implement new features without protocol updates -more permissionless from a dev pov.
On the other hand, narrow types create a well-defined, well-scoped environment, easier to navigate for devs who want to implement a standard feature set.
What's your take?
Signers (rebranded as app keys) are extremely powerful, but I think they are becoming a disaster waiting to happen. Users are not aware how to manage them, and even if they were, there are no reliable tools to do so.
Does anyone else share the same concerns? If so, what can we do to improve them?
Does anyone else share the same concerns? If so, what can we do to improve them?
During the dev call today, @v said they are working on prototyping snap chain consensus using Informal System's malachite, which promises fault-tolerance and censorship-resistance. https://informal.systems/blog/interchain-meet-starknet
You can follow this channel to keep up-to-date with new FIPs.
Right now, there are two FIPs that are very active:
- "Add location to user data".
This one feels more mature and close to moving to the next stage (Review). It will allow users to set their location and store this information on the protocol. You can set your location in Warpcast today, but this piece of info is not stored on hubs and is not available to other apps and devices. https://github.com/farcasterxyz/protocol/discussions/196
- "Add location type as a valid Embed type":
Allow casts to embed location data. Is less mature than the above FIP. https://github.com/farcasterxyz/protocol/discussions/197
Great conversations under both of them.
Right now, there are two FIPs that are very active:
- "Add location to user data".
This one feels more mature and close to moving to the next stage (Review). It will allow users to set their location and store this information on the protocol. You can set your location in Warpcast today, but this piece of info is not stored on hubs and is not available to other apps and devices. https://github.com/farcasterxyz/protocol/discussions/196
- "Add location type as a valid Embed type":
Allow casts to embed location data. Is less mature than the above FIP. https://github.com/farcasterxyz/protocol/discussions/197
Great conversations under both of them.
Thanks to everyone (esp @v and @sanjay) who pointed out flaws in the original design of my Farcaster Ordering proposal, I feel that the current one is much more mature.
> There is a mempool where every hub submits deltas. Miners propose new blocks, each block is linked to the previous one in a blockchain. Anyone can spin up a miner.
> Miners have to stake (lock) an amount of ETH. The amount is not fixed and may go up automatically if many miners compete in block creation. The stake is not slashed or lost in any way, but it will remain locked for 100 days, before the miner can withdraw it.
> The architecture takes advantage of the OP sequencer (onchain events) which in practice becomes the Farcaster chain’s clock. Forks are very rare, but can be resolved if/when they happen. The design provides good censorship resistance.
Details: https://gist.github.com/vrypan/1ae6a60ecb3741ab031b5b06c974acab
> There is a mempool where every hub submits deltas. Miners propose new blocks, each block is linked to the previous one in a blockchain. Anyone can spin up a miner.
> Miners have to stake (lock) an amount of ETH. The amount is not fixed and may go up automatically if many miners compete in block creation. The stake is not slashed or lost in any way, but it will remain locked for 100 days, before the miner can withdraw it.
> The architecture takes advantage of the OP sequencer (onchain events) which in practice becomes the Farcaster chain’s clock. Forks are very rare, but can be resolved if/when they happen. The design provides good censorship resistance.
Details: https://gist.github.com/vrypan/1ae6a60ecb3741ab031b5b06c974acab
A concern about rate-limiting users: There are cases when a user may have to submit a big number of deltas. For example, to restore their past activity from a backup, or to re-sumbit deltas with a new signer.
Will these use cases be blocked by rate limits?
Will these use cases be blocked by rate limits?