💾 Archived View for rawtext.club › ~sloum › geminilist › 004761.gmi captured on 2024-02-05 at 11:18:48. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Mansfield Mansfield mansfield at ondollo.com
Thu Jan 7 04:38:32 GMT 2021
- - - - - - - - - - - - - - - - - - -
Hello!
I've been enjoying the gemini-space and I'm excited that this email signalsmy attempt to join more vocally. Hopefully my attempts to support Geminiend up being acceptable or at the least agreeable. :-)
I've been working on a server and client for Gemini and I'm nearing the endof what I wanted to explore in my implementations... but I have a fewquestions that I'd love some help thinking through. I'd like to cover oneof those questions in this email.
One of my goals has been to have a client / server pairing thatsupports helping non-technical users go from downloading a client toposting content as quickly and painlessly as possible. In my mind thismeans allowing new accounts to be created *without* moderating theircreation... which leaves me wondering how I might respond to side-effectslike any unwelcome content (illegal, offensive, spam, etc.).
I understand that walking down a path that allows un-moderated accountcreation is asking for trouble. I'm still interested in exploringthe possibilities to see if a compromise might be found formy implementations.
One of the options I'm considering is to restrict the number of posts a newaccount can make. Say, only "one page"? This wouldn't remove *all* negativeside-effects, but seems to discourage some abuse and facilitate anyclean-up since there'd only be one 'thing' to remove.
Another option is to limit the *kind* of content that a new account canprovide. Say, no links? This could curtail a type of side-effect(facilitating access to external content through my domain/server), but notentirely, since text/gemini *without* explicit links could just as easilybe a link-in-plain-text that is copied and used somewhere else.
A third option I'm considering is to limit the visibility of the contentthat a new account can provide. I've written an HTTP server that providesaccess to the Gemini content, so, maybe I disallow any content fromaccounts less than say, 1 month old? If a new account were showing promiseas a positive contributor I could manually enable it sooner than a month...a sort of default-deny with a manual-allow. Content could of course stillbe viewed through a Gemini-specific client, just not through a web browser.
The last option I've been mulling over is to just accept the side-effects,but that feels too much like an ends-justify-means approach which I findweak as a motivation... but... I *almost* prefer encouraging communicationand creation enough to endure negative side-effects.
I guess one way to sum up the sharp corner I'm trying to round-off is thatI have two goals that seem to oppose each other: encourage creation ofcontent *and* discourage creation of 'wrong' content. I'm very sensitive tothis concept of 'wrong' content too... (I'm *very* uninterested in limitsto agency, but there's the swinging fists and noses point in the middle ofthat)... but that's a different discussion.
I have memories of some server implementations simply requiring manualaccount creation approvals, which, as mentioned, is what I'm hoping toavoid... I *know* this is a tough complication. As some additionalinformation, all I have set up as required for account creation is toprovide a certificate. I plan on using the subject-common-name and firstfew characters from the generated fingerprint as the account name... so...no email verification, and no way to know if some spammer is just creatinga bunch of new accounts for similar purposes.
There's more thought I've had, but I'll stop rambling there.
Thanks for reading this far. :-D
Thoughts?-------------- next part --------------An HTML attachment was scrubbed...URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210106/0b144906/attachment-0001.htm>