## This document reflects my thoughts about PSYC ## which are some years old. Please try to imagine ## what I would do now as I haven't updated this. ;-) =========snap========= The trick is: The user chooses his "home address" which is a server probably in the vicinity. This server is the place where he announces his existence and which workstation & port number he is actually on. Pending notifications can be handled then. So a user can have an URL, like this: psyc://psyc.site.edu/~lynx/ And channels themselves are better permanent (they only disappear when you explicitely declare them dead), and are defined in the same way at home sites: psyc://psyc.site.edu/@channel/ So a user simply needs to have the psyc-interface in his .mailcap file, and as soon as the WWW browser encounters such an URL, the psyc-"client" is fired up to handle that communication (be it one person or a channel). =========snip========= * Chatnet does not address geographical ordering. I have realised that due to * this fact, a search on users in a particular geographical or IP domain will * be hard to implement. Chatnet could use help on this. Directory servers, one for each continent. Things like that. But what's really important: We don't need any directory facility to already be a good IRC replacement. It's just less fun-value, the work-value is the same! * The functions of the contact board and the radio broadcast are also worth * investigating. A major problem will be the notification service, as the user * base is not global. The privacy constraints make things even more difficult. As you have a fix address for a user, the place where *he* promised he would be signing up, notification requests can be waiting there, and as the user signs on, they can be handled automatically, or in any other way if the user desires (privacy issue). * has gone. This way, it is harder to annoy ppl, and it is easier to "run away" * and get rid of this nasty guy. If someone doesn't like you, you might even have his address, if he ignores you you might have a hard time tracking down what channels this person is on. It's not like IRC where it's enough to patch an IRC server to get that info. * If you want to meet your friends at the conference service, make an appointment * with them to be on a certain channel or place or whatever. The channel space * then needs to provide a larger diversity to "store" large amounts of people. Just as diverse as the Internet itself. Any internet host can be a channel bearer. The host is part of the name - at least technically. On the user interface, you might just display the name. * I was thinking about a usenet-like hierarchy, which could also provide a * geographical oriented way of finding users, eg de.oldenburg.chat. This needs * a more hierarchical way of structuring protocol entities as well, e.g. * client - server - hub. I have not worked out this idea yet. And I've been thinking of WWW, and placing channels in the middle of pages that deal with certain arguments. So channels become a hyperspace instead of a hierarchy. Since channels are supposed to be programmable, it can be implemented that channels have exits, as in MUDs, so you can move to related discussion fields, without activating your WWW browser. Whatever people like - it should be possible to do. What's best will turn out as the system runs. * If you are in the neighbourhood at that time, you might drop by to discuss * things in real life :) It's in my calendar -- Groningen is the nearest interesting city to Oldenburg as far as I've heard.. haven't been there yet though. It's a good thing to have an excuse to come. :-) =========snip========= Gerrit Hiddink typeth: * What I also want is a channel key to get ops on a channel if you know the * key. The current IRC protocol does have something like that (I believe), Yep.. mode +k. But that's something that can be definined in the channel control program, which is absolutely up to the channel owner to implement if he wants to. That is, we can provide default channel programs, but everyone can extend the idea and build whole WWW areas and file servers into the thing. The so-called "channel-bot" becomes the steering wheel of channels and is no longer a net-hog as it was on IRC. I'm planning to let the servers fire up a rexx interpreter to interpret the channel programs. But any other implementation can be thought of. The channel program receives all join requests, and can freely (by any algorithm, even by interactive query to the other channel members or whatever) decide if someone may join or not. * though it is not used often. But the channel wars have to be stopped, or * at least it has to be made more difficult to "hack" a channel and lock * it up. On IRC this can be done with only two smart bots. In my concept, only someone who manages to let the channel owner or his bot give the authority to an other bot + owner can take over control, in both negative and positive sense, of the channel. No protocol hacks should be possible, only pure human treason. And since typically there is no need to give out authority of your channel, people will need to convince others pretty hard. * In chatnet a server can announce the starvation of a channel. Currently, * I think it is best to do this as soon as the channel is empty, so that the * channel space will not get crowded with unused channels that ppl forgot to * kill, or that they want to reserve, keep for theirselves or for whatever * reason. Since there is no database, there is no need to kill empty channels. Empty channels only consume space on the server that defines them, and maybe on the directory services (WWW pages) that reference him. That's all. Either the channel owner(s), or the admin of the channel server can remove a channel. A channel is one or more data files, which the channel program keeps in whatever way. Plus a channel program, if the channel program is nonstandard. To make up your own channel program, you need to run your own channel server (unless your channel server is actually a MUD, then a wizard could be enabled to configure a channel etc.) =========snip========= For the concept of #report channels, that is: news channels with many listeners and few speakers, the channel program can be implemented such, that: - The clients do not get a list of people on the channel, so they cannot speak (moderated channel by force). - The clients simply receive the news from the speakers, and/or from channel program or any other authority .. that's completely up to the channel program to define! - When they reply to the speakers, they just send a private message to them, they can't speak to the whole channel as they just don't know who's on the channel and will never find out (unless the channel program allows). =========snip========= * hmm yes. although I want to bother ppl as little as possible with protocol * information, such as "what server is a certain user on". The way the undernet * ppl have solved this, is to register a DNS domain undernet.org, so that * servers in holland are *.nl.undernet.org. The same way, IP addressing could * be made more "compatible" with real-world addressing schemes, so that a user * can guess the IP hostname of a server a certain user could be registered on. You can directly reference people by nickname whose URL you have stored in your client (or your WWW hotlist). Others are indeed not trivial to find, but any directory service that is being provided for WWW, can also be used for the interactive URLs, the psyc: URLs. Directory services for WWW are being implemented everywhere. =========snip========= You think my structure is bureaucratic, but instead it is democratic! It gives the simple man, given he can compile a program, the ability to set up his own server, his own client, his own channel, where NO ONE can come and spy on him, or disrupt his channels. Not even a server admin, as the server admin is he himself. Up to now, that power was only granted to those who are able to run an IRC server. Why do you think IRC has so many vanity servers? Well in my concept, the geek who makes his own server, doesn't have *any* advantages than when he uses somebody else's server. He can just be sure that the server isn't hacked. And he can customize his channels. Since there is no state data being broadcast throughout the net, one server more or less makes just about no difference. It's just a bit of CPU time in exchange for a server that is closer to you. Servers only provide the information who's there and who's on a channel. Servers don't even communicate between each other. Don't be confused of what you call a server. To me what you call a server is a router and a server at the same time, like ircd. One program doing two completely different jobs. * hmm if the channel program resides at the channel server, then how does the * sender know to what channel servers it has to send the data? or to what When you join a channel, you send the join command to the channel program. The program decides if you may join (check for a list of invitations, or check a list of bans, or ask the people which already are on the channel, or simply allow anyone in.. any politics are fine and can be implemented), then it sends you the list of people that are on the channel. From then on you send your data directly to the other channel members and you don't send anything to the channel program. When you leave the channel you send a message to the group that you are leaving. That's why a message transfer protocol capable of routing a message to a list of addresses would be a good thing to have, instead of sending a packet to each. You may now say that this means carrying big collections of addresses around the net for each message. And I say that if you want to implement channels, where the routing medium already knows who belongs to that channel, you are very welcome to do so and I will adapt my clients and channel programs such that they can make use of such a medium, so the choice is up to the user, because both principles have their advantages and disadvantages. =========snip========= * > The other problem with your concept is, that if the channel is available * > everywhere, you cannot control it - anyone who owns a server can pretend * > he's channel op and you get the usual shit problems you have with IRC. * * Yep. As I mentioned earlier however, chatnet provides mechanisms to * resolve inconsistent data. I have not yet defined in detail how Well in my scheme the users have the list of people on they channel. If they hack their clients to add or remove people, they will simply send their own messages to one person more or less. Big deal. All authority comes from the channel program, and whoever can control it. That makes for a pretty safe construction. The less beautiful aspect of list-type channels is the way the list of people is specified in each packet a person sends out. (The list splits as it reaches routers who forward the message into different directions). This doesn't scale very well. Many channels are no problem, but channels with many people. Fortunately they are not so popular. Anyway I would like to be able to use the IRC-type channel routing as well, so it's up to the channel creator to use a list, a channel, or a hybrid. If you are going to write routers capable of keeping information on channels and where they need to be routed, then I'd bring my stuff to use it as well. * inconsistencies in user and channel modes are handled, (these are the * most tricky ones) but if one server says "YES he is chanop" and the other * says "NO he is not" then there is at least an exceptional situation that I suggest you leave that out. Implement my authority principle where only authorized network objects (the channel programs) may declare who is joining a group, who is being kicked from a group, and what characteristics the group has (i'm afraid the only other one is moderation, everything else is handled by the channel program internally - the so-called chanops, the topic, join passwords, invite-only etc. etc.). When a hacker tries to spoof a message from the channel authority to let him join the channel or kick someone off it, the router immediately sees that it's coming from the wrong direction and gets angry. That solves a lot of problems, doesn't it? No more chan ops on the net, they are all defined in the authority where there cannot be inconsistency. =========snip========= * You will have to update directory services if these spots move around. Now Authorities may be added, but why should they be removed - Especially the originating one that gave the channel its name? If the channel owners decide to move a channel, that's ok, and then also the URLs will have to be fixed. But believe me, this will hardly ever happen. If gnu decides to run a gnu.announce type channel, then it will forever run on psyc://prep.ai.mit.edu/@gnu.announce Everyone is trying to make channels permanent, just think of all those reservation bots. If they *are* indeed intended to be permanent, you'll see that acceptancy for the whole medium will be raised tremendously. Everyone who's able to click on an URL will be joining this or that channel, and many of them will find a channel where he wants to stay whenever he logs in! And it will always be the same channel with the same people. No hackers, no strange modes, no unexpected bots. * Hmm as routing is a major problem in the IRC protocol, I directed my * attention to routing first. For me it is a primary issue, as it determines * the functionality that can be offered to the layers above. If the routing * layer cannot provide certain functionality, then that will have its impact * on the layers above. You are right.. but I realised that having no routing is also better than IRC. That's why I was thinking to first go without it, but if you are doing it I'm happy. =========snip========= * So there is very little information, if any, that has to traverse unknown * pieces of the net. This also means that it is hard to find channels you * don't know yet. Nice for privacy, but bad for the popular "channel hopping": Correct. * wandering around, hoping to find a channel that is friendly, cosy, weird * or sexy enough, depending on what the user is searching for. That's what WWW is for. Netsurfing at its best. You look up WWW pages that advertise fun channels, you choose one whose description appeals to you and you hop on it. No problem. :-) Since just about everyone can write WWW pages there are thousands of people who could be doing the directory service job. And they will do it much better than if I were to implement a directory service. Probably there'll be many collections of "The best channels on the net" and some will get very popular I suppose. Everyone will keep his favourite channels in his homepage. There'll be thousands of ways to get to a channel. * I think dcc is still good enough, it is used a lot to transfer files * on the fly while being engaged in a conversation. A direct TCP link would * lighten the task of the conferencing system. I have thought of adding a little more structure: - MIME types, compression and encryption info are passed. - The TCP link can be used for conversation as well, before or after the file transfer.. it's not a must, it's just possible. So DCC doesn't exist in my concept, it's integrated, and it's up to the client program to open up a new TCP connection or use something it already has. * If you do not trust other channel servers, then a channel servers cannot * cooperate with other channel servers, thus centralizing the task of serving Yes I am centralizing the task of administrating the channel, but I'm not centralizing the communication that takes place on it. I believe that's acceptable, and it dissolves all state problems by definition. Should I be wrong and another choice is better, we can still implement it. The concept is open for extension. But I don't think you can prove I am wrong, cause at least for small secure channels it sounds like damn good idea. And that's what I care for most. * So I think that you either have to trust the servers you cooperate with, * risking the chance that they have been tampered with, or distrust other * servers and do everything yourself. The latter I plan to do, but I'm open to alternatives, as long as everything can be done. That means, a user can choose to have a channel with distributed control or with centralized control. If you want to make distributed control, okay, let's do that as well. I'll find a way to make channel programs work with that as well, they will just be an interface for people on WWW to join the channel etc, but they won't have any more control over the channel than you give them. But please also implement for my type of channels. So we get a fertile choice of implementations and experience will show which strategy is the best for which situations. =========snip========= We can have half the work each, all we need to do is to agree on the message protocol and a few basic control commands a channel authority may issue. I think these are: - channel is open/closed for anyone to join - channel is open/closed for anyone to send messages to (from outside) - channel is moderated (only the channel authority speaks, moderators send their talk to the authority which forwards it into the network --- no +v type mode thing!!) - person joins a channel - channel authority is added Maybe I forgot something. I have it written down at home in my new specs for psyc. Your server would need to understand the same messages from the authority as my clients do (in a direct list-type channel) =========snip========= Gerrit Hiddink typeth: * I think that we are both working at different layers of functionality. You Correct, that's what I noticed too. * So one would say that the handiest thing to do is to merge our ideas and Hey great! I should read your messages before I start replying to them.. ;-) =========snip========= * As for the name of such a hybrid system: I think its is the best to find * a new name for it. One of us would feel injust if the other's name is given * to the hybrid creation. I'm afraid in many english-speaking ears chat sounds like fun and of no professional use. That's exactly what your protocol isn't. I had thought of MTP (Message Transport Protocol) for the layer, that I'm not planning to implement anymore. But it might aswell be Message Routing Protocol, or Channel Routing Protocol since the multicast aspect is characteristic. For my part, I'm not too proud about Protocol for SYnchronous Conferencing, but hey... Anyway I describe a layer on top of yours, so why shouldn't they have seperate names and even be distinct products, although designed for cooperation. After all ircd and ircII aren't from the same people either. Ok my layer is much more than just a client... * sharing work seems most suitable to me, as this will also shorten the time * it takes to make an implementation. EFnet is falling apart rapidly, so * something better is needed soon... The sooner the better. I'm not so good at long runs, they kill me energy. I would really like to see something work in the first place, be it only a prototype. * I must warn you that I am quite stubborn (as is the case with most * programmers). So I feel strongly the need to implement my idea just as it * is, to prove that the idea works. Or to see why it does not work (in spite * of ppl telling me why it would not work). The experiences thus obtained I understand that and my policy is: If you don't know, implement both! The other policy however is: If you don't have the time, just implement one! ;-) * can be used to build a routing layer for psyc. Furthermore, if two fully * functional conference systems arise from our ideas, they should be compatible * and able to exchange information invisibly for the user. The time of a Would be nice if all different types of channels and lists could be created, yet the clients are able to handle them all and the user doesn't have to act different according to the protocols, he just "feels" the difference. * dozen small IRC networks should end, since it fragments the user base, * decreasing the "cosyness" factor. The "cosyness" factor... I'll put that in my .signature or somewhere. * I do not know exactly yet what we can do together. For Gronics I must * continue working on my original idea, what I have to do for my graduation * assignment is not known yet. So it is pretty vague what possibilities lie * open right now. I hope to get cleariness on my assignment this week. Only * time will tell... SEND ME THOSE SPECS! :-) =========snap=========