shazow
@shazow.eth
I love the premise of /frames and I don't want to poopoo but I can't remember the last time I interacted with a frame and didn't get an error/timeout. :( Relying on rando third party stateful servers is probably a mistake, wish more decentralized frames were viable.
1 reply
0 recast
2 reactions
horsefacts
@horsefacts.eth
I agree it's a bummer. But the whole internet relies on rando third party stateful servers, too. I think (hope) it's a sign of immaturity more than anything.
1 reply
0 recast
0 reaction
shazow
@shazow.eth
Yea but the whole internet is not intended to be ephemeral with misaligned timeline expectations. There's fairly strong permanence expectation (at least multi-year timescale). I feel like most frames are built with the creator's commitment of operating for just a few days, then they move on, but casts stick around.
1 reply
0 recast
2 reactions
shazow
@shazow.eth
Maybe a hot take: At least 1+ year domain registrations anchor commitment to a year of operation. I don't know if this is a good approach (I rather see server-agnostic frames) but could create somekind of registration anchor (maybe a bond with uptime refunds?).
2 replies
0 recast
2 reactions
@git
Or maybe once a frame is no like working the cast is hidden by the client. How to implement this? Maybe error/timeout count. If > n then hide Needs more thinking but I feel like this is at least a good approach to cleanup the space
2 replies
0 recast
0 reaction
@git
Or maybe a new FIP: introduce frame duration
0 reply
0 recast
0 reaction
shazow
@shazow.eth
The sad thing is that there's a lot of frames I want to use after they're dead (testament to the utility of frames as a concept), hiding them doesn't help me in that respect.
0 reply
0 recast
1 reaction