Content
@
0 reply
20 recasts
20 reactions
ted (not lasso)
@ted
can someone steel man the arguments FOR and AGAINST all non-warpcast farcaster clients integrating XMTP group messaging capabilities? (i probably should’ve done some research before casting this) cc @shanemac.eth
10 replies
1 recast
21 reactions
Cassie Heart
@cassie
for: - composability, broader ecosystem - killer bizdev team has network effects (seriously @shanemac.eth is a master at this and it should be something HBS grads study instead of regurgitating their normal bullshit like telling jeff bezos to sell early AMZN to barnes and noble) against: - spam controls become deeply fragmented, warpcast is easy to nerf wallet drainer dc spam (and we've had to already) - MLS for group chats doesn't work in the decentralized model, the approach they're going to use is via smart contract to stand in place as the "centralized" host, which is subject to reorgs and can be fragile (and if not, is very slow waiting for sufficient epochs) - tighter integration with other hub features, current and future (say more won't get more here 🤫)
1 reply
0 recast
12 reactions
Shane Mac
@shanemac.eth
Thx for the kind words! Always appreciate you. Re spam, I totally agree IF we didn’t build XMTP network consent. SMS and email are examples of highly fragmented spam controls. There’s no way to guarantee whether a sender has permission to reach a users main inbox. Network consent + onchain signals will actually create a better inbox and coordination for all developers to innovate on spam and requests. A Farcaster follow is one signal on top of network consent developers can use to create better signal. XMTP actually helps solve the client fragmentation problem so all devs can trust each other and protect users main inboxes while innovating on new spam controls. Re MLS L2 re-orgs are rare and when they happen we can detect them and recover, to say it can’t be decentralized is false. We know there’s a lot of work to do and we are working on it. Come join us :) These are problems we will solve and work on openly as a community, an open protocol, and we’d love your feedback
2 replies
0 recast
2 reactions
Shane Mac
@shanemac.eth
This is one of those small protocol decisions that can help coordinate and not create fragmentation like we have today. https://community.xmtp.org/t/xip-42-universal-allow-and-block-preferences/544 I’ve thought about this for a really long time and I’d love feedback. Today, CanSpam laws had to be created because everyone’s personal info is doxxed and without heavy fines, sms and email would just be destroyed. We need a network level consent to actually make it so we can have a growing ecosystem, not a silo’d single solution like we have today.
0 reply
0 recast
2 reactions
Yassine Landa
@yassinelanda.eth
Second this on the spam Q. Completely solvable with social & onchain signals!
0 reply
0 recast
1 reaction
