Services

From The Socknet

A service is a website that interacts with the Socknet.

In the Socknet protocol, a service is represented by an object with a serviceid field.

Example:

{ serviceid: "http://awesome_website.com/serviceid.json"
}

The serviceid field holds a URL to a JSON document on the Internet describing the service's name and other crucial information.

The ServiceID serves as a unique identifier of the service.

The ServiceID should lead to a document with an object with this structure:

{ name: "Service X",
  agents: ["192.58.15.2", "worker1.servicex.com"],
  base: "http://servicex.com/",
  api: "http://servicex.com/socknet.api"
}

The name field is a human readable name for the service.

The agents field is described in IP Verification.

The base field contains a URL to the human-usable "home page" of the service. The base must be in the service's directory space. Providers should show the base URL alongside any messages shown to a user. This enables a user to identify the service by more than just its name.

The api field is optional. If it exists, it is the URL for functions which can be called on the service. IE, it operates like a Provider URL but for services.

Sub Items

Directory Space

A service's directory space contains all the directories at or below the same directory level as the ServiceID itself. If the base is not in this space, then the whole service should be ignored.

This is the only restriction regarding the directory space. The objective is to ensure that the base URL is controlled by the same entity that controls the ServiceID URL. If this is true, then the service is considered "legitimate", to the extent that it is verifiable by the user.

To be clear, a service may choose to store its messages at any Internet address and may link to information anywhere on the Internet. (At one time, this was not the case. If you find references to any other use of directory spaces in these documents, please delete them.)

Considerations

The name is a nicety and may be changed at will. However, it probably shouldn't be, partially because providers are not required to check it again after the first contact, and partially because changing it would confuse users.

Although there will be services that attempt to impersonate other services, they will be mostly ineffective, because users can identify them by their URL's. This is as fool-proof as anything on the web.

Services should have user-friendly base URLs. This makes them seem more trustworthy to users. They may not be more trustworthy, but a complicated base URL is a sure-fire way to seem less trustworthy. Ergo, a trustworthy service will make its URL as simple as possible. And so will an untrustworthy service.

The Socknet is comprised of users who send messages to each other. A service cannot get its messages onto the network unless some user uses it. There is no way that a service can force users to pass around messages. There are hash mechanisms in place to stop a service from using bait and switch tactics.

The directory space rule gives a fair degree of certainty that the user who controls the ServiceID page controls the base URL.

Take an example:

serviceid: http://domain.com/agents.json

{ name: "Awesome Website",
  agents: ["192.168.15.2"],
  base: "http://domain.com/"
}

In this example, the agents.json file is at the root of the server. The root is generally only accessible to the server's webmaster (if this is not the case... well, it should be). So we can be sure that the owner of the server has written this list of agents. If someone else created the service, it's a sure thing that they trust server's owner pretty well.

Example 2:

serviceid: http://domain.com/blog-monster/blog/agents.json

{ name: "Blog Monster",
  agents: ["192.168.200.200"],
  base: "http://domain.com/blog-monster/blog/index.html"
}

In this example, the agents.json file is at the same level as the service. Clearly the file was created by someone with access to the service's files. So anything in it was created by people who control the service.

In general:

A website user that can upload files can usually control a particular level and everything below it. There is a level at which the user cannot "go up" any further. Therefore, the level that an agent list is at is the highest level that the agent list can have any authority over.

"at or below":

In comparison to this address:

http://a.com/b/c