@solderpunk if you do finalize the gemini spec soon, one thing to address should be streaming responses (i.e. infinite length response bodies). There's a thread about it. The tl;dr is that you can't stop me from sending an infinite response therefore clients must deal with it or subject themselves to DoS therefore it should be officially permitted

@sir @solderpunk when spec in finalized, is it going to be submitted to the ietf? Cuz having an actual RFC would be cool and lend gemini some legitimacy.

@zethra @sir I am not opposed to this in principle, and I've tried to always act as if it were a thing which might happen some day (so I've tried to e.g. avoid anything in the Gemini spec stepping on the toes of any other RFCs). But in truth I have very little idea of what would actually be involved in this, and what the likely result of the process would be in terms of how much it would open the protocol to the influence of third parties.

@solderpunk fair enough I suppose. I also have no experience with submitting an RFC but @sir does with BARE. So, maybe he'd be willing to lend you some insight. Not that I can or would volunteer his time if he's not interested.

@sir @zethra Oh, that's great! I was unaware of BARE. I might send you an email about this in the near future.

@sir @solderpunk Can you expand on the DoS problem? Is it about memory starvation?

@alvarezp @solderpunk yes, or any other number of resources depending on how the client is implemented

@alvarezp @solderpunk I could also just slowly trickle random data to you a few bytes at a time so that your client never finishes loading the page

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!