-
Notifications
You must be signed in to change notification settings - Fork 1
0 of 5
Our first step is to define an API for our component. We have to figure out what that component is meant to provide to its users before we can do this.
This component is a messenger. It shall provide a number of functions:
- A message can contain arbitrary content.
- Sender can tag a message to declare its content.
- Sender can sign messages.
- Receivers can verify (or not) signed messages.
- Users can chose what chose communication channels (will be discussed in more details later)
This is only a messenger. It can be more. You could specify message content in more details and make it a more specific app like a decentralized location aware game, a digital payment solution, an advertisement system etc. pp.
Unfortunately, most people think of server based application when we talk about social networks. We all know the big players in the market. There are also decentralized social networks out there.
Unfortunately, nearly all of them use Internet as communication channel without further consideration. That consideration is necessary. Message encryption is even provided by centralized huge social network providers. Nevertheless, our privacy can and is tempered. Meta data are fare more interesting than the actual data.
Social network analysis is based on information who talked to whom when and maybe where. The actual content would be nice to have and is not necessary. Collecting those metadata is trivial on server based applications. It can and is done on the server.
Internet communication can and is monitored. Decentralized applications using Internet cannot circumvent that fact. Collecting metadata becomes more complicated but is still possible.
We have no plans to argue about the used communication channel. We do not even promote another channel. We simply claim: It should be users choice. This messenger can be configured to be behave like any other server based messenger. It can also be configured to provide insanely high security needs. And anything in between.
User should be able to choose their communication channel. They can use Internet and a single centralized entity if they feel comfortable with it. They should be able to use e.g. the TOR network if more privacy is wanted. They should even be able to decide to use their very own communication medium (there is a ASAP sub project that uses LoRaWAN that allows creating your very own wireless communication network on an urban scale). Finally, users should also be able to decide to only use short range ad-hoc networks like Bluetooth.
This messenger takes whatever communication channel is available and allowed by its users.
We use three terms for classification:
Stone age Messages are only exchanged within ad-hoc networks. Messages are routed. It is like a network that is based solely on oral communication – like in the stone age. Users can copy a message and forward it. That is called gossiping. An automated message routing is not provided.
Bronze age Messages are only exchanged in ad-hoc networks like in the stone age. Messages are also routed, though. User Alice could send a message to Bob. Bob would automatically forward the original message to another user, let’s say Clara. It is like exchanging paper written notes. Each peer would make forward an exact copy of each received note.
Iron age Message are exchanged even over long-range networks. Users can barely estimate risks of potential spies.
- Project goals
- Step 0: Concept
- Step 1: API
- Step 2: Implementation
- Step 3: Shark Component
- Step 4: Testing
- Step 5: GUI
- Javadoc
- Shark Messenger User Guide
- How to use
- Command Page