Duke Wiki  logo
Child pages
  • Linking Spaces
Skip to end of metadata
Go to start of metadata

Just as web pages may be hyperlinked to each other, Cobalt spaces may be linked, too, allowing you to connect your spaces with spaces owned by other users.


To protect privacy and ensure security, Cobalt prevents unauthenticated users from opening links to other users' spaces. Before you can link spaces, you must complete a one-time registration of your Cobalt identity. Whenever you wish to communicate with other users or link to their spaces you will first need to log in to Cobalt with the User ID and Password you establish during registration. See Registering Your Cobalt Identity for more details.

Linking Two Spaces

To link your space with another user's space both spaces must be running and both of you must be logged in. Cobalt's built-in chat service provides the mechanism for linking.

  1. Login to Cobalt: Cobalt > Login
  2. Open a chat session with the person whose space you wish to link to your own space: People > Text Chat Window
  3. Once you've established a chat session, a Join button will appear within your chat window that's associated with the other person's space. Click the Join button to send a request asking for permission to establish a link.
  4. A popup screen will ask what kind of link you wish to establish: one-way or two-way. A one-way link allows travel from space A to space B, but NOT from space B to space A. A two-way link allows travel in both directions. You'll also have the option of requesting a Teleport to the other user's space. Teleporting does not link the two spaces.
  5. Once the other space owner has approved your link request Cobalt will open a portal providing entrance to the linked to space.

Persistence of Links
The links remain only as long as the Cobalt spaces are running. If you or the other person close down your Cobalt space the links are broken and must be re-established by starting a new session.

  • No labels

1 Comment

  1. If you have a problem linking two worlds, the odds are good that the dispatcher config is broken in some way, or your local network does not match my assumptions.  I've tried to make the standatd config as generic as possible but there are a lot of ways to organize a network.
    I really should document the dispatcher/router config file more, but it's still changing.   This file is to be placed in the root folder for the app (same as the .image files), and should be named cobaltbrowserouter.st.   It is read in at viewer startup time and is used to configure the router, dispatcher and the authentication services. It's just a chunk of Smalltalk code that returns a configuration object as this was the easiest way I could think of to get it working.

    There are 2 stanzas that matter at present, the first is a block that will return a dispatcher configuration and the second is to set up the auth services. In the standard config, the dispatcher block is setup to configure a Universal Plug and Play firewall hole (if one is available) using the TUpnpDispatcherConfig. The other options are a LAN only config (TLanOnlyDispatcherConfig) and a fully manual config (TManualDiapatcherConfig).  These all can be sent the routerClass: method to set up the kind of router that get spawned on connection. I expect we won't be changing this much but it's been useful for testing. There is also a localAddressString: method they all understand.

    The Squeak TCP/IP interface is somewhat badly done and doesn't really understand having multiple active TCP/IP interfaces....they seem to have made an assumption that there is only one interface active as would be common in a workstation.  Servers, or a workstation running VMware or Parallels will often have more than one active interface. If you ask for the local interface address, it will give back it's best guess....which is often wrong if you have multiple interfaces.  {{The localAddressString:}}method is there to specify the interface we want to advertise, in the cases where the automatic approach is giving us wrong answers.  In the provided file I have the localAddressString: send commented out, but if Cobalt Master isn't starting up properly try uncommenting it and setting the address string to the IP address you want to use.  In testing will work, it just won't let anyone else get a reasonable address to connect to you.

    For the TLanOnlyDispatcherConfig there are no other options.  For the TManualDispatcherConfig there are a bunch of options so you can specify the address on the other side of the firewall and the port numbers.

    The auth services stanza I'm going to leave for later, except to note that the auth service named Local is special and is the service used if a service is not otherwise specified when the controller tries to log in.