## 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. ;-)
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:
And channels themselves are better permanent (they only disappear when
you explicitely declare them dead), and are defined in the same way at
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).
* 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. :-)
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
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.)
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).
* 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.
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
* > 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.
* 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://email@example.com
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.
* 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":
* 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
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.
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
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)
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.. ;-)
* 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
For my part, I'm not too proud about Protocol for SYnchronous Conferencing,
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
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
* 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! :-)