Andrei O.

@andrei0x309

754 Following

2374 Followers

Andrei O. pfp

This is because capital and VC funds, 90/100 of tribalism, and moats, and silos are caused by that. I wrote code that integrates with most social protocols and platforms out there, for me it's clear that no one wants to build the best social protocol for users. It might be impossible to do so in this economic paradigm.

0 reply

0 recast

2 reactions

Andrei O. pfp

Wrote a super tiny logger lib for slack logging `slack-logger-light` with an example of integrating it with @tsed/logger, I know there are already a lot of such libs but this one has 0 deps. And might be the best in certain scenarios. https://bit.ly/4fUFewg

0 reply

0 recast

1 reaction

Scout Game pfp

1. @earth2travis 🏅 Talent Score: 85 2. @web3pm 🏅 Talent Score: 85 3. @tieubochet.eth 🏅 Talent Score: 112 4. @andrei0x309 🏅 Talent Score: 80 5. @sinaver.eth 🏅 Talent Score: 106 Congratulations! 🥳 Keep scouting and building for your chance to be on the leaderboard next week. 💪

2 replies

1 recast

10 reactions

Andrei O. pfp

Coming from someone who wants to see capital power diminished, the reality is that capital is needed in order for any project to survive, if that wasn't the case, like if we lived in a different world where capital was not needed to survive decently then a native token would not be needed for the network, as people could sustain a network just by being interested in it. In layman's terms, the native token is there to create revenue for a network to at least cover the compute costs, but sometimes will also create profit, that's not 100/100 required but covering the cost is.

0 reply

0 recast

1 reaction

Andrei O. pfp

Looked at it, and the biggest breaking change seems to be publishing the app metadata on-chain that's used in authentification. I didn't look deeper if this kills Momoka, but I suspect it makes sense for all posts to be in a single place not like before on-chain and on a data availability layer. The spam will be countered with daily limits of probably 200 like before, it's refreshing to see not an aggressive focus on increasing DAUs, protocols don't care about DAUs, only capital mainly cares about DAUs, you can have the greatest protocol with only one user, it makes no difference as long as you don't want to enrich yourself. Also, an important concept is bringing your own feed, this is crucial to new social media and it's hard to believe decentralized social media will succeed with obtuse centralized feed algorithms.

0 reply

1 recast

12 reactions

Andrei O. pfp

Veto power is always undemocratic, and should not exist at all but it exists in so many systems including in many EU procedures. I don't think anyone can say democracy and veto power is compatible with a straight face.

1 reply

0 recast

1 reaction

Andrei O. pfp

It can go through some hoops but it executes in ~20s, with low fees, IMO doesn't seem very brutal to me, I am not looking for under ~1s confirmations, for value transfers, I think anything that is below 1m is great.

0 reply

0 recast

1 reaction

ccarella pfp

Farcasters ship! Some recent GitHub activity via @scoutgamexyz Feat. @ba @andrei0x309 @sayo @cris and more.

1 reply

4 recasts

8 reactions

Andrei O. pfp

On server code with bun or deno TS is first class citizen, I don't see any reason to not use TS, as everything is handled internally by the runtime, so if you are using a newer runtime, I don't see why anyone would avoid types. Plus even in the frontend world, most bundlers are so much better nowadays, the days of writing 2k lines of Webpack configs are over.

1 reply

0 recast

0 reaction

Andrei O. pfp

I've been suggesting that for a long time for performance and scalability everything has to be moved including FID, storage, on FC as a Blockchain. Also simple token mechanics should be implemented to allow for FID payments, implementation does not need to be Turning complete, many blockchains didn't have smart contracts.

0 reply

0 recast

0 reaction

Andrei O. pfp

For PWA both are ok, PWA does not need a server so a PWA can be both an SPA or an SSR app. Reasons to use Remix over Next: 1 You have an internal app that does not require SSR 2 You're pleased with SPA indexing and think SSR will not bring many SEO benefits 3 You don't own the API that you're using 4 App is mostly interactive with not much text 5 Your Next servers are crap(AKA maybe you self host) 7 You want a lighter framework where you have more control but have to build more 8 Main target audience has fast internet Reasons to choose Next over Remix: 1 SEO is supercritical even with non-google engines Yandex, Bing, brave, etc 2 You don't care about costs 3 Target audience has slower internet 4 You want to write less code 5 You want more libraries and better support 6 You prefer stability over latest features I am sure that there are many more points it also depends on your project, also other frameworks are nice SveleteKit is great Nuxt is not bad, I've been using 4 to 5 frameworks lately.

1 reply

0 recast

4 reactions

Andrei O. pfp

If SPA is an absolute requirement you can only go with Remix.

1 reply

0 recast

2 reactions

Andrei O. pfp

Wildcard client was a great addition to the ecosystem. Glad to hear you have something else lined up, I'll surely check it up when it arrives.

1 reply

0 recast

1 reaction

karan 👑 pfp

After a remarkable journey, we've made the difficult decision to sunset the Wildcard client. I want to express my deepest gratitude to our community. Your support has been invaluable. It was real fun building for you guys and iterating on the product together. While this is a bittersweet moment, I hope this will be a start to an even more exciting chapter. We are building and we'll be cooking stuff, will stick around here, keep you guys posted on what's next! Thank you to everyone who were with us all the way till here, for your unwavering support!

39 replies

11 recasts

171 reactions

Andrei O. pfp

The way the hand is held to me just looks like: "goodbye America".

0 reply

0 recast

1 reaction

Andrei O. pfp

I never saw any feed algorithm that does not consider time somehow. But warpcast backend algorithms are closed source so, unless they are made public is all speculation, and no one can give you a definitive answer. I think this is a better question for the /warpcast channel.

1 reply

0 recast

1 reaction

Andrei O. pfp

It was asked many times before, this question started to appear even a month ago. It would make sense with a permisionless mini app but right now only whitelisted mini apps can be opened. It is a client feature entirely though. https://warpcast.com/andrei0x309/0xeec65f91

0 reply

0 recast

0 reaction

Andrei O. pfp

Is not ok, they need to have an account at all times, they may delete your app if they can't access it with user/password. They do manual reviews from time to time, the above app has like 2 and half years in store it went through like 4-to 5 manual reviews. Over 60 native version submissions. If they can't log in they will delete the app and reinstate it after you provide a way to log in that they like, warpcast login might be rejected by Google folks, better to have a user password flow to be safe.

1 reply

0 recast

1 reaction

Andrei O. pfp

If you have a store account, you're basically required to have a login with one of your users, they won't bother to review with wallet, though I also shared a seed on Google Play. Fun fact all these posts that this account made https://yup.live/profile/test200/feed were done by Google employees.

1 reply

0 recast

1 reaction

Andrei O. pfp

Mitigates the worst effect of sibil, where one human controls 500k accounts. It has the drawback that most proofs require some form of KYC, though there are a few that do not. Human verification it's still valuable even if an account does automated actions because it's stamped by a human and that means all actions are taken with the approval of the human.

0 reply

0 recast

1 reaction