# What’s next for Farcaster? (Apr 23)

With the launch of Hubs now in its final phases, we wanted to recalibrate our priorities as a community. This document is a draft of some goals, problems and a few early solutions and we’re looking for input from casters.

## Goals

1. Increase the number of people creating useful content on Farcaster.
2. Increase the number of developers building on Farcaster.
3. Achieve credible neutrality.
4. Make money to keep funding protocol development.

## Stack-Ranked Problems

### Make sure that Hubs are working as expected

Hubs have launched but we haven’t hit our goal of 10 stable hubs and don’t have great reporting. Most apps aren’t reading from hubs and only writing, which means this area is untested and may have bugs or complications that emerge later.

- What can we improve to get Discove, Jam and Yup to move over to reading from hubs?
- Ship Hubble v1.1 and get 10 external hubble instances running.
- Get to permissionless mainnet hubs asap.

### Educating users and developers

Figuring out how to do things with [farcaster.xyz](http://farcaster.xyz) is hard — whether its learning about how it works, standing up a hub or getting access to data on a hub. If you search for farcaster you land up on farcaster.xyz which gives you answers to some of these indirectly and after many many clicks, and sometimes not at all.

- Build a new landing page that clearly targets the different groups: users who want to try farcaster apps, developers who want to integrate with farcaster content and developers who want to contribute by writing code or running hubs.
- Improve the protocol documentation so that it is easy for someone reading it to start developing a hub in another language.
- Improve the github documentation so that there are no issues with the examples and other common areas of the codebase.

### Developers do not have the freedom to implement new ideas.

The protocol is somewhat restrictive and we’ve discussed why its important to give developers [more degrees of freedom](https://hackmd.io/@farcasterxyz/Hyyt7NFb2) to develop new ideas.

- Add flexible types to reactions and casts to enable polls, commenting on nfts etc
- Add network separators to allow users and apps to keep content separate across networks.

### App-Driven Signups

Applications should be able to get users to sign up to Farcaster without relying on approval or infrastructure from Warpcast. There are a few different ways we can achieve this:

- Give applications more freedom to invite users
- Farcaster can extend the invite service infrastructure to allow other apps to invite users.
- Warpcast can give all application developers a large number of invites to bring on users.
- Farcaster can launch the contracts on mainnet and make signups permissionless.
- Reduce application reliance on Warpcast
- Farcaster can develop a dapp that allows signer management from any arbitrary wallet, which means that users can store identities in metamask and log into Jam, though the experience won’t be as nice as the Warpcast flow.
- Farcaster can create a general purpose social wallet desktop app which warpcast and all other apps in the ecosystem can rely on for signers.
- Other applications should lean into becoming wallet applications.

### Long-term data storage

Applications are already starting to store historical data — warpcast and greg’s indexer are already doing this implicitly. If there isn’t a standard format for how the data is preserved then users may run into trouble when migrating content between servers and realizing that some of it is missing or cannot be translated.

- Create an “archive” format for snapshotting older data and backing it up to a file.
- Extend hubs to store longer durations of data while the network is still small.
- Allow flexible hubs that can choose which users to sync and what duration to hold.

### Make money so that we can fund the ecosystem

Farcaster doesn’t have its own funding mechanism and relies largely on contributions from other developers. This will need to change to ensure that the protocol stays independent.

- Charge users for the amount of data stored on hubs, either right now or when we get to testnet. The amounts may be minimal (<$1/month) for most users but they will establish the pattern for driving protocol and test the hypothesis that users are willing to pay.