Lily
Start of topic | Skip to actions
Whenever a new feature is suggested, it is often summarily rejected
(not by me, mind you. =-) as being contrary to the "design goals". A
very brief summary of these goals is (a) support the TelnetProtocol, (b) allow
users to protect themselves from other, malicious users.
From CoKe on the lilycore-dev mailing list
I am not sure what gave rise to this particular statment, but suffice it to say that 'a' is a design goal of gangplank, not of lily. The text-mode on lily is only accessible by telnet for extremely loose interpretations of "accessible." And that is an accident of history more than an intentional thing because I started working on lily by telneting to it. It was shortly afterward that I wrote the first client (lclient, now clily) which provided the necessary interface elements to really make use of the system. Since that time, any action on my part to preserve the semantics of the text agent are more to maintain the stable function of older clients rather than to preserve telnet access. Is it bad that telnet access is possible? No. It is not, however, a fundamental principle of lily according to the list I enumerated below.
-- ChristianRatliff - 15 Apr 2004
These notes were dated 30 Dec 1998: lily is an interactive Computer Mediated Communications (CMC) server. Essentially, this means that it allows people at different places to talk to each other via computer. lily is a real communication tool. It was, and continues to be, designed and developed - with real people in mind. The initial goal was to improve online, real-time, communication between individuals and groups of people. lily is flexible. An equally important secondary development goal of the project was to provide flexibility to programmers to experiment, accommodate and adapt lily under a wide variety of methods and formats for communication lily is freedom of choice. lily supports both personal and professional communication and it does so without one type interfering with the other. While the initial goals for the project have been met, the development continues. We're always looking for ways to improve on its ease of use - of ways to help foster and facilitate interactive communication by and between real people.
Let me outline two very important concepts, which must be held in consideration before digesting these principles. First, these foundational ideas on which lily was designed and built appear, in the text below, to be almost like a set of bright lampposts. As if they somehow physically illuminated the thinking which lead to lily. For the most part, that could not be further from the case. The principles were more like atoms, invisible yet ubiquitous. I doubt very much that I was consciously aware of the zeroeth principle, and yet I am more than certain that I was always deeply aware of its implications in what I was doing. Second, and proceeding from what I just illustrated. These atoms pre-existed or were imparted to me through interaction with other people. From the very first day I set foot on the campus of RPI, I was in love with CMCs. Being introduced to them by ChesireCat? in the VCC, I could imagine nothing more I wanted to do than to study them and build them. Since that day I worked on easily a dozen different systems and talked endlessly with people who taught me much about the difference between the code and the culture of the CMC. When I first began, this difference was not obvious to me, as it is not obvious to many developers new to the world of CMCs. In conceiving our designs and executing their authoring into code, we need to be motivated by a sense of the community we are supporting. What is their culture? What are their practices? What are their needs? If your actions are motivated by a need to implement a specific feature because you consider it cool, then it is likely to languish unused. To those people who taught me so much about CMCs during my long apprenticeship, I give you my sincere thanks. You are likely to recognize yourself in the list you find below. No successful CMC is the work of any one person. That being said, here are the fundamental tennets under which I operated when designing and implementing lily: 0] lily is a village. This implies that lily is a structure based on tight interpersonal relationships. It is not a city where vast migrations and changes in the community are common. A city has a long institutional memory and an almost smothering lack of anonymity. In the village every person has a name, a face and a history. In a village you know who dated whom and when. In a village there is restraint, except at the local biker bar (wank). Because lily is a village accounts are created by a person rather than automatically. This keeps the pace of account creation down and virtually eliminates tourists, since it is too hard to get into the village just to peep around. The only people who move here are those with a close personal relationship to someone living in the village now. Those who move here out of curiosity quickly find the place stiffling and move on (with notable exceptions). 1] Names are forever! A frequent abuse on Clover was to log in quickly, do something harrassing and then log out immediately. Because your name was arbitrary, it was lost the moment you logged out. The /IGNORE command no longer had access to that identity so you could not defend yourself next time the person connected. This problem could also have been dealt with by item #2, but no such people existed in real terms. As a result of this, lily was designed specifically to have a set of names which you could use. Those names are semi-permanent so that you can always get back to to that person. Further, the /FINGER, /IGNORE, and /GROUP commands give you access to those names so that you can identify, block and track people even when they are not connected. A record of every name change made is also stored in the system log file, which gives evidence to just how important names are in the lily system. 2] The lack of administration leads to anarchy. Clover was a realm of total chaos. If someone was acting inappropriate and blocking them was impossible, there was essentially no one to turn to. rhysomme had no effective administration interface even if there was someone to turn to. Further it was designed to be that way with a very rich (or complex if you like) permissions system which enabled the user to control every aspect of communication. In the end, the design flaws and implementation bugs, many of which were my own fault, prevented the system from being useful in that area. By comparison CONNECT was a much quieter system with strong administration and much lower levels of conflict. Though it had strong administration, they were not actively mediating every dispute, leaving nearly all of the problems to be resolved by the users, yet still being present. Responding to this situation, I built lily in the CONNECT style. There is an active administrative interface complete with commands to do many common operations (including make accounts like in #0). The administrators are quietly in the background, but well known figures (Isis and Garance). People turn to them to resolve problems rarely, but occasionaly, and their decisions, in my experience, are always quite deliberate and deliberated. In my view, there is a distinction between developers (Ach, Coke, etc) and admins. Developers should shut the heck up with regards to policy decisions and confine themselves features and bug fixes.
Was I good at that? Perhaps later in life I got the picture, but it took a LONG time.
The one place I went wrong is with the $head_admin feature. If I could I would go back and remove that feature because it is simply too abusable. (RemoveHeadAdmin)In fact, I would like to suggest it be removed for 2.8.0.
3] People need to be reasonably safe from predation here.
In any village there will always be people who just do not get along. Whether on the basis of their prior history together, a frequent occurance, or simply for reasons of personal style or bearing, the situation will nonetheless exist. Just as it does in the real world, the resulting social breakdown will cascade into many areas of the communal life. In the physical world social conventions and distance generally prevent explosive confrontations, but there is no social convention in anonymity neither is there distance on the Internet (where nobody knows you're a dog). In the most severe case, where a person is threatened by another user, they must have facilities to shield them at least equal to those available in the practical world. In all cases, the system itself should provide nearly every necessary capability, resorting to administrators to resolve these problems does no one good. Administrators do not have the wisdom of Solomon, after all who does? In almost every case, the community itself, by turning a cold shoulder, can eject a sufficiently vile predator, but in a very few rare cases administrators have had to step in. This is vitally important when threats move from the online world to the real world. No administrator should stay their hand in the face of harrassment transitioning from online to real world.
lily is profoundly changed by this principle. Each user has access to a variety of commands which can be used to filter the output the receive from lily. These features vest in the user control for moderating their own access to lily, thereby permitting them to remain active and engaged even in the presence of withering harrassment. The commands are organized in a hiearchy of importance:
7] Small tasks make for a completed project.
It has been my experience, based on years of working on CMCs, the larger the undertaking the less likely it is to be implemented. It is this idea, and the prodding of Maker, which attracted me to MOO. It allows for extremely rapid development of small pieces, gradually forming into a larger system. This has been a source of constant frustration for people who would like to convert lily into something more rigorously designed and developed.
If any of these principles are thought to be outmoded and undesirable, then change them. However, if you do, I would please ask you to rename your effort. The system that would result is not lily.
-- ChristianRatliff - 06 Aug 2003 (updated 07 Aug 2003)
Do you draw a distinction between text-the-protocol and text-the-encoding? Would a lily that let us write in Japanese through any mechanism not be lily? -- masto
Excellent point, Christopher. Though there was a time when I did not see the distinction, I mostly certainly do now. text-the-encoding is perfectly acceptable to me, and the principles should include that notation.
-- ChristianRatliff - 07 Aug 2003
to top
These notes were dated 30 Dec 1998: lily is an interactive Computer Mediated Communications (CMC) server. Essentially, this means that it allows people at different places to talk to each other via computer. lily is a real communication tool. It was, and continues to be, designed and developed - with real people in mind. The initial goal was to improve online, real-time, communication between individuals and groups of people. lily is flexible. An equally important secondary development goal of the project was to provide flexibility to programmers to experiment, accommodate and adapt lily under a wide variety of methods and formats for communication lily is freedom of choice. lily supports both personal and professional communication and it does so without one type interfering with the other. While the initial goals for the project have been met, the development continues. We're always looking for ways to improve on its ease of use - of ways to help foster and facilitate interactive communication by and between real people.
Let me outline two very important concepts, which must be held in consideration before digesting these principles. First, these foundational ideas on which lily was designed and built appear, in the text below, to be almost like a set of bright lampposts. As if they somehow physically illuminated the thinking which lead to lily. For the most part, that could not be further from the case. The principles were more like atoms, invisible yet ubiquitous. I doubt very much that I was consciously aware of the zeroeth principle, and yet I am more than certain that I was always deeply aware of its implications in what I was doing. Second, and proceeding from what I just illustrated. These atoms pre-existed or were imparted to me through interaction with other people. From the very first day I set foot on the campus of RPI, I was in love with CMCs. Being introduced to them by ChesireCat? in the VCC, I could imagine nothing more I wanted to do than to study them and build them. Since that day I worked on easily a dozen different systems and talked endlessly with people who taught me much about the difference between the code and the culture of the CMC. When I first began, this difference was not obvious to me, as it is not obvious to many developers new to the world of CMCs. In conceiving our designs and executing their authoring into code, we need to be motivated by a sense of the community we are supporting. What is their culture? What are their practices? What are their needs? If your actions are motivated by a need to implement a specific feature because you consider it cool, then it is likely to languish unused. To those people who taught me so much about CMCs during my long apprenticeship, I give you my sincere thanks. You are likely to recognize yourself in the list you find below. No successful CMC is the work of any one person. That being said, here are the fundamental tennets under which I operated when designing and implementing lily: 0] lily is a village. This implies that lily is a structure based on tight interpersonal relationships. It is not a city where vast migrations and changes in the community are common. A city has a long institutional memory and an almost smothering lack of anonymity. In the village every person has a name, a face and a history. In a village you know who dated whom and when. In a village there is restraint, except at the local biker bar (wank). Because lily is a village accounts are created by a person rather than automatically. This keeps the pace of account creation down and virtually eliminates tourists, since it is too hard to get into the village just to peep around. The only people who move here are those with a close personal relationship to someone living in the village now. Those who move here out of curiosity quickly find the place stiffling and move on (with notable exceptions). 1] Names are forever! A frequent abuse on Clover was to log in quickly, do something harrassing and then log out immediately. Because your name was arbitrary, it was lost the moment you logged out. The /IGNORE command no longer had access to that identity so you could not defend yourself next time the person connected. This problem could also have been dealt with by item #2, but no such people existed in real terms. As a result of this, lily was designed specifically to have a set of names which you could use. Those names are semi-permanent so that you can always get back to to that person. Further, the /FINGER, /IGNORE, and /GROUP commands give you access to those names so that you can identify, block and track people even when they are not connected. A record of every name change made is also stored in the system log file, which gives evidence to just how important names are in the lily system. 2] The lack of administration leads to anarchy. Clover was a realm of total chaos. If someone was acting inappropriate and blocking them was impossible, there was essentially no one to turn to. rhysomme had no effective administration interface even if there was someone to turn to. Further it was designed to be that way with a very rich (or complex if you like) permissions system which enabled the user to control every aspect of communication. In the end, the design flaws and implementation bugs, many of which were my own fault, prevented the system from being useful in that area. By comparison CONNECT was a much quieter system with strong administration and much lower levels of conflict. Though it had strong administration, they were not actively mediating every dispute, leaving nearly all of the problems to be resolved by the users, yet still being present. Responding to this situation, I built lily in the CONNECT style. There is an active administrative interface complete with commands to do many common operations (including make accounts like in #0). The administrators are quietly in the background, but well known figures (Isis and Garance). People turn to them to resolve problems rarely, but occasionaly, and their decisions, in my experience, are always quite deliberate and deliberated. In my view, there is a distinction between developers (Ach, Coke, etc) and admins. Developers should shut the heck up with regards to policy decisions and confine themselves features and bug fixes.
Was I good at that? Perhaps later in life I got the picture, but it took a LONG time.
The one place I went wrong is with the $head_admin feature. If I could I would go back and remove that feature because it is simply too abusable. (RemoveHeadAdmin)In fact, I would like to suggest it be removed for 2.8.0.
3] People need to be reasonably safe from predation here.
In any village there will always be people who just do not get along. Whether on the basis of their prior history together, a frequent occurance, or simply for reasons of personal style or bearing, the situation will nonetheless exist. Just as it does in the real world, the resulting social breakdown will cascade into many areas of the communal life. In the physical world social conventions and distance generally prevent explosive confrontations, but there is no social convention in anonymity neither is there distance on the Internet (where nobody knows you're a dog). In the most severe case, where a person is threatened by another user, they must have facilities to shield them at least equal to those available in the practical world. In all cases, the system itself should provide nearly every necessary capability, resorting to administrators to resolve these problems does no one good. Administrators do not have the wisdom of Solomon, after all who does? In almost every case, the community itself, by turning a cold shoulder, can eject a sufficiently vile predator, but in a very few rare cases administrators have had to step in. This is vitally important when threats move from the online world to the real world. No administrator should stay their hand in the face of harrassment transitioning from online to real world.
lily is profoundly changed by this principle. Each user has access to a variety of commands which can be used to filter the output the receive from lily. These features vest in the user control for moderating their own access to lily, thereby permitting them to remain active and engaged even in the presence of withering harrassment. The commands are organized in a hiearchy of importance:
- /IGNORE can be used to block messages from being sent to you from a particular user. This feature is centrally important and has existed, to varying degrees, in all of the RPI CMCs since CONNECT.
- /NOTIFY
- /BLOCK
- /IGNORE PUBLIC
- Why is there no /CLOAK or /HIDE command? (ImplementCloakHide)
7] Small tasks make for a completed project.
It has been my experience, based on years of working on CMCs, the larger the undertaking the less likely it is to be implemented. It is this idea, and the prodding of Maker, which attracted me to MOO. It allows for extremely rapid development of small pieces, gradually forming into a larger system. This has been a source of constant frustration for people who would like to convert lily into something more rigorously designed and developed.
If any of these principles are thought to be outmoded and undesirable, then change them. However, if you do, I would please ask you to rename your effort. The system that would result is not lily.
-- ChristianRatliff - 06 Aug 2003 (updated 07 Aug 2003)
Do you draw a distinction between text-the-protocol and text-the-encoding? Would a lily that let us write in Japanese through any mechanism not be lily? -- masto
Excellent point, Christopher. Though there was a time when I did not see the distinction, I mostly certainly do now. text-the-encoding is perfectly acceptable to me, and the principles should include that notation.
-- ChristianRatliff - 07 Aug 2003
to top
Edit | Attach image or document | Printable version | Raw text | More topic actions
Revisions: | r1.10 | > | r1.9 | > | r1.8 | Total page history | Backlinks
Revisions: | r1.10 | > | r1.9 | > | r1.8 | Total page history | Backlinks
Lily.FundamentalPrinciples moved from Lily.FundamentalPrinciple on 07 Aug 2003 - 13:30 by ChristianRatliff - put it back