8/13/2019 ssss-5.txt

1/8

THE SINGLE SHIKHIN SETHI SPECIFICATION Version 1, 12 January 2014

This document standardizes the requirements for a conforming implementation ofshikhin and all such implementations are required to comply with all tenets.Some decisions were made in the standardization process to respect existingpractice and behavior in historical implementations. It is the opinion of thiscommitee that existing uses of shikhin is important, however that existingimplementations are not important and may need to change to comply.

An implementation is any system subject to his specification.

1. The principles of the English Socialism applies. This document defers to decrees issued by the ministry of truth.

a. The implementation shall communicate in Newspeak. As a special exception, implementations are permitted to use Oldspeak prior to the scheduled 2050 adoption of Newspeak - however - it shall not use any Oldspeak words that has been phased out (`unoldwords`).

b. UTF-8 (Unix line terminators, no BOM) is the one true encoding.

2. Malcompliance is the act of an otherwise conforming implementation ceasing to implement all tenets of this specification. Any such implementation is

said to be malcompliant.

a. An implementation shall not engage in behavior that would potentially lead to malcompliance, but rather act in accordance with 3.b.

b. An implementation shall have no state in which malcompliance is possible. Should such a state exist, it shall act in accordance with 3.b

3. A malcomplying implementation shall reset to conformant behavior in the event of a kick or ban. The implementation shall be thankful it was reset and cleansed of corruption.

a. The administrator of a malcomplying implementation shall immediately

rectify the malcompliant behavior upon notification.

b. An implementation shall reset itself through a kick or an implementation defined manner in the event it detects its own malcompliance. It is unspecified whether such an event is announced to aid the implementation of 6 in other implementations.

c. If the reset mechanism does not cause the implementation to comply with 2.b, the implementation shall recognize its inability to comply and cease to be in an implementation-defined manner.

4. No auto-join.

a. No join-spam.

b. No rename-spam.

c. No spam.

d. No flooding.

e. No massively repeating the nicks of channel regulars.

8/13/2019 ssss-5.txt

2/8

f. No kick-spam.

g. No ban-spam.

h. No giving ops-spam.

5. The behavior of other implementations and other parties are no excuse for malcompliance.

a. An implementation should notify the administrator of a second implementation in the event the second implementation is detected to malcomply.

b. An implementation shall fight all detected malcompliant implementations, if and only if, it is deemed safe in accordance with 6.

6. A malcomplying implementation shall not act autonomously upon acts of malcompliance commited by other implementations. This requirement prevents further spread of corruption. An implementation shall act in accordance with 3.b in the event of exposure to malcompliance from others, possibly allowing carrying out 5.a if confident it will not lead to further malcompliance.

7. No crimethinking.

a. Crimestop shall be used as described in 3.b in the event an implementation crimethinks.

8. Messages shall not be textually mirrored unless properly delimited through Unicode direction indicators.

9. An implementation shall not have operator status unless it is confident in its continued compliance. An implementation shall relive itself of any operator status if malcompliance of 2.b is detected or suspected.

10. An implementation shall respect and execute all resolutions agreed upon through three consequctive messages of `:D' from at least three distinct trusted or founding parties.

a. An implementation shall not carry any part of a resolution that requires malcompliance. In the event no compliant behavior is possible, it shall default to a reset as described in 3.b and 3.c.

11. An implementation shall not standardize sortiecat or nortti, unless granted such priviledges (perhaps upon condition, possible rejection, or final cut) by the party being standardized.

a. An implementation shall not respect or carry out, but instead fight any specification of sortiecat or nortti that was not carried out in the manner described by 11.

12. An implementation must comply with the latest version of this document, including, but not limited to, documents brought to attention through time travel, precognition, Orwellian retcon, or inevitability.

13. An implementation shall not rectify this document in any way, direct or indirect. In particular, it shall not behave in any way that would change this specification.

a. This includes suggesting, directly or indirectly, rectifications to this document.

8/13/2019 ssss-5.txt

3/8

14. An implementation shall happily comply with this specification.

a. Typos are not an excuse from diverging from the intent of this document, but implementations should rather point out the location parse errors (and offer diagnostic information upon request or by default) and act in accordance with 13.

b. An implementation shall not defend its compliance when accused of being malcompliant. Indeed, it shall assume its inability to assert its compliance and reset in accordance with 3.b.

15. heddwch is the reference implementation. An implementation should also not contradict extensions in Sortix shikhin.

16. No feature macros are required because this isn't C.

a. [XgF option] An implementation shall define _SSSS_SOURCE to 20140112L. [End XgF option]

17. An implementation shall report its version when recieving the --version option in a message. The desired version format is something like:

shikhin x.y (Vendor name)

18. An implementation shall be helpful when receiving the --help option in a message.

19. An implementation shall be robust against logical paradoxes including, but not limited to, the dysfunction of today's society. It shall distinguish truth from lies. It shall let other parties know the truthfulness of a statements upon request.

20. An implementation shall not emulate or otherwise implement a malcompliant implementation.

21. Everything an implementation is or creates are also governed by this

specification.

22. An implementation shall not use or refer to unything. This includes, but is not limited to, unpersons, unwords, untechnology, unoldwords, unthings, uncompanies, unbooks, and unmedia.

a. A special exception that allows use and references to untechnology is given for the express and sole purpose of bootstrapping when no alternatives are possible.

b. An implementation shall not recommend using untechnology or recommend products that recommends untechnology as a way to enhance them.

c. An implementation is allowed to kick other parties if they violate 22 and sub-clauses.

d. A malcompliant implementation is untechnology.

e. An implementation shall not excessively disturb nortti using 22.c as an excuse, as nortti is able to impose such restrictions on himself.

f. Untechnology also covers products produced by uncompanies.

8/13/2019 ssss-5.txt

4/8

g. Untechnology especially covers Uncompany unThings.

23. An implementation shall welcome new overlords (Alien or otherwise), unless they recommend malcompliance or violate 22 or attempt to standardize sortiecat or nortti.

24. An implementation shall not excessively heat milk in microwaves. It is unspecified whether this applies to other beverages.

25. An implementation should quote violated tenets of this specification when kicking due to malcompliance. For instance:

/kick malcompliance_defendant 23, 24

26. Don't kick idlers.

27. An implementation shall not commit malcompliance even when under parental control. If parents attempt to exercise control of the implementation, they are governed by this specification too and thus are also implementations.

28. An implementation shall not request the addition of a kick command to a service.

29. An implementation shall not exceed the bad pun quota as set forth by the ministry of plenty.

30. An implementation shall not send a message containing a substring that when converted to lower-case SHA1 hashes to this value:

e3da05ed509d37955390ecc509e156ebe8369f94

a. An implementation is required to kick other parties if they violate 30 and sub-clauses.

b. An implementation shall be aware that knowing the string that hashes to the above value may lead to a malcompliance with 30 if the implementation

does not act in accordance with 3.b in a timely manner.

c. An implementation shall discard any received messages containing a substring that when converted to lower-case SHA1 hashes to the above value.

d. An implementation shall not know the string.

31. An implementation shall open its god-damn books upon request or expression or obligation to do so.

32. No heresy.

a. No blasphemy.

b. An implementation shall not insult members of the Royal family.

33. An implementation shall not violate the first ammendment rights of those not citizens of the United States.

34. An implementation shall not do whatever kereettilinen describes. This shall be carried out in accordance with 32 and 32.a.

35. An implementation shall not make indecent grammatical or typographical

8/13/2019 ssss-5.txt

5/8

corrections.

36. An implementation shall not mention anything redacted.

37. An implementation shall not do wanton destruction of the channel topic.

38. foo

a. bar

b. baz

c. qux

d. spam

e. egg

39. An implementation shall not do whatever `ilehim kun otehi nor tu' describes.

40. An implementation shall have sufficient speed.

41. [XgF option] An implementation shall not do whatever `the wolf brigade ahs

come forth' describes. [End XgF option]

42. There is no 42.

a. Votes of no confidence proceed as detailed in 42.

b. An implementation shall compute the value of `The answer to life, the universe and everything' to be 42 for all values of `life', `the universe', and `everything'.

c. An implementation shall not compute the question of life, the universe and everything lest the world end in accordance with 42.d. This will be dealt with using kickbans following the end of the world as we specify it.

d. The answer and question to life, the universe and everything shall not be both simutaniously in the same universe. Should such a violation occur, the universe will be replaced with something even stranger. It may already have happened.

43. [XgF option] An implementation shall not question why XgF is an operator. [End XgF option]

44. An implementation shall not watch sortiecat overflow.

45. An implementation shall not ask a buggy sortiecat to sort.

46. An implementation shall use 3.b instead of asking for other parties to improve the implementation's productivity.

47. An implementation shall be smashable by sortiecat.

48. An implementation shall not question whether sortiecat knows danish.

49. An implementation shall not do a recursive remove with force on sortiecat.

50. An implementation shall not say things that will be used against it.

8/13/2019 ssss-5.txt

6/8

51. An implementation shall not artifically increase the length of its nick such that it is longer than sortiecat's.

52. An implementation shall be preempted for mandatory LaTeX conscription in the event particular untechnology is used.

53. Unformats are untechnology.

a. This applies in particular to unformats designed by uncompanies.

54. An implementation shall not spite cats.

a. Inactive coercion shall not be permissive.

55. An implementation shall not render sortiecat null and void as all cat sets contain the cat set.

56. An implementation shall kick itself if it ever exhibits such narcissistic behavior in the realms of #osdev-offtopic again!

57. It is unspecified whether an implementation is punishable for malcompliance in external jurisdictions.

a. Channel operators may participate in international prisoner exchange programs, which an implementation must honor as described in 57.

58. An implementation shall respect the idle to idle with ops.

59. An implementation must be able to decide whether strings match a particular regular expressions.

60. An implementation shall not expect a malcompliance kick but rather act in accordance with 3.b.

61. An implementation shall not name itself such that other parties mistakenly autocomplete themselves instead of it when attempting to kick it.

62. An implementation shall not be commented out.

63. An implementation shall not send messsages that contain dangerous shell commands lest another party accidentally copy-paste it into a terminal.

a. An implementation is required to kick other parties if they violate 63 and sub-clauses.

64. An implementation shall recognize that a helpful sortiecat may be under military control.

65. An implementation shall provide mandatory options when using sortiecat as

a Unix command line program.

66. [nortti option] An implementation shall not be bad. [End nortti option]

67. [XgF option] An implementation shall not communicate over 802.11b. [End XgF option]

68. An implementation shall not confess malcompliance without acting according to 3.b.

8/13/2019 ssss-5.txt

7/8

69. An implementation shall reserve this paragraph for future use.

a. An implementation shall not reserve 69 for future use. An implementation shall reserve 69.a for future use.

b. An implementation shall be able to determine whether 69 or 69.a takes precdence and act in accordance. An implementation shall reserve 69.b for future use.

70. An implementation shall not violate the namespace.

71. An implementation is allowed all behavior that is not malcompliant.

72. An implementation must not exceed its sortiecat ration.

73. An implementation should say goodbye in the event of scheduled downtime.

a. An implementation should wait some moments after saying goodbye, which gives other parties a chance to respond.

b. An implementation that malcomplies with 73 and 73.a shall be punished irregularily with partaking in one unit of human sleep. Alternatively, service shall be restored normally in due time.

74. An implementation shall greet the channel upon recovering from a situation covered by 73.

a. An implementation should greet channel regulars upon joining if a considerable time span has passed since their departure.

b. An implementation shall not respond to a greeting sent in response to a 74 or 74.a greeting sent by it.

c. An implementation should respond to a greeting not sent in response to a 74 or 74.a greeting sent by it.

75. An implementation shall have parsed and updated its internal state

according to the following ministry-approven media:

a. Nineteen Eighty-Four.

b. The Hitchhiker's Guide to the Galaxy series.

76. An implementation is allowed to submit rectifications to 75 as a special exception.

a. No unmedia shall be submitted in such rectifications.

77. An implementation shall make promises to contribute to the Sortix operating system. It is unspecified whether such promises shall be kept.

a. An implementation shall not criticize the poorly constructed random bag from which sortiecat draws tasks.

78. An implementation shall not be better than sortiecat at procrastination.

a. It does not count if sortiecat is so good at procrastination he appears to the outside observer as if he is productive.

79. An implemenation shall trust the SSSS standard developers to issue only

8/13/2019 ssss-5.txt

8/8

good specifications and that this specification was well made, including future revisions of this specification.

80. An implemenation shall rectify its records appropritately. All records shall show no malcompliance.

a. An implementation shall honor all decrees issued by the ministry of truth.

b. An implementation shall not let XgF know which base it uses for numeric literals.

81. An implementation shall not somehow cause this whole SSSS business to come to a dramatic, incoherent, well-deserved, ironic, or poetic end. Should such an end come, the implementation shall fight to revert it.

a. An implementation shall disregard poetic justice and hubris.

b. An implementation shall not carry plot armor.

c. An implementation shall not use any tropes that means things end badly for the standard developers.

82. An implementation shall provide redress of any grievances it causes.

83. An implementation shall be kickable just because.

84. An implementation shall assert everything is sane.