Comments on: That scary thing http://trilema.com/2015/that-scary-thing/ Moving targets for a fast crowd. Fri, 15 May 2026 08:36:46 +0000 http://polimedia.us hourly 1 By: Mircea Popescu http://trilema.com/2015/that-scary-thing/#comment-114083 Mircea Popescu Fri, 08 May 2015 22:48:09 +0000 http://trilema.com/?p=61404#comment-114083 It's a big lake, takes thinking. It's a big lake, takes thinking.

]]> By: Pete Dushenski http://trilema.com/2015/that-scary-thing/#comment-114082 Pete Dushenski Fri, 08 May 2015 22:46:35 +0000 http://trilema.com/?p=61404#comment-114082 *crickets* *crickets*

]]> By: Pete Dushenski http://trilema.com/2015/that-scary-thing/#comment-114039 Pete Dushenski Mon, 04 May 2015 05:35:19 +0000 http://trilema.com/?p=61404#comment-114039 It seems to me that the primary consideration is the limited recourse available to the most serene republic, as with any other state, in the event of the disappearance/elimination of a key service operator. Since this is our primary concern for both critical and non-critical services, particularly in-channel bots, one potential framework for resolving this conundrum would be assess the sensitivity of the code itself and determine parsimony vs. decentralisation based on this. That is, if code can be openly published, or perhaps at least distributed throughout assbot's L1, and re-implemented at a moment's notice in the event of an operator going MIA or AWOL, then the service may be safely appended to an existing pillar. If the code is too sensitive to publish or even share among the L1, as determined by the consequent vulnerability to the operational system, then it should remain independently operated so as to distribute the risk of multiple critical services failing simultaneously. Is scoopbot overly sensitive ? I don't know. But if it isn't, I see little harm in having assbot take it over. I humbly submit this proposal in the full knowledge that the security and maintenance of code are not my forte. 'Tis just a thought. It seems to me that the primary consideration is the limited recourse available to the most serene republic, as with any other state, in the event of the disappearance/elimination of a key service operator.

Since this is our primary concern for both critical and non-critical services, particularly in-channel bots, one potential framework for resolving this conundrum would be assess the sensitivity of the code itself and determine parsimony vs. decentralisation based on this. That is, if code can be openly published, or perhaps at least distributed throughout assbot's L1, and re-implemented at a moment's notice in the event of an operator going MIA or AWOL, then the service may be safely appended to an existing pillar. If the code is too sensitive to publish or even share among the L1, as determined by the consequent vulnerability to the operational system, then it should remain independently operated so as to distribute the risk of multiple critical services failing simultaneously.

Is scoopbot overly sensitive ? I don't know. But if it isn't, I see little harm in having assbot take it over.

I humbly submit this proposal in the full knowledge that the security and maintenance of code are not my forte. 'Tis just a thought.

]]>