diff --git a/community.drawio b/community.drawio index f945fe2..6d44260 100644 --- a/community.drawio +++ b/community.drawio @@ -1,195 +1,195 @@ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + @@ -197,229 +197,335 @@ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - + + - - + + - + - - + + - + - - + + - + - + - + - + - + - + - - + + - + - - + + - + - + - + - + - + - + - + - + - + - + - - + + - - + + - - - - - + + - - + + - + - - + + - - + + - - + + - - + + - - + + - - + + - - + + - - + + - - + + - - - - - - - + - - + + - + - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/community.png b/community.png index cc2e990..3d4da89 100644 Binary files a/community.png and b/community.png differ diff --git a/community.svg b/community.svg index dec7c5f..e62b5de 100644 --- a/community.svg +++ b/community.svg @@ -1 +1 @@ -
Admin
Admin
Trust
Trust
Support
Support
User
User
U1 sendet Geld zu U2
U1 sendet Geld zu U2
U1
U1
U2
U2
U4, Trust Mitglied der Community,
bestätigt Schöpfung von U3
U4, Trust Mitglied der Community,...
U4
Trust
U4...
U3 meldet eine Schöpfung in
seiner Community an
U3 meldet eine Schöpfung in...
U3
User
U3...
Community
Community
Eine Community hat Nutzer mit verschiedenen Rechten.

Die User können Geldschöpfungen anmelden und Überweisungen tätigen. Der Support hat erweiterte Einsichtsrecht in Kontobewegungen und ergleichbare Berechtigungen um Nutzern zu helfen. Trust bezeichnet den Teil der Nutzer, welche Geldschöpfungen bestätigen können. Administratoren kontrollieren darüber hinaus die nötige Infrastruktur und stehen somit an der Spitze der Kontrolle über die Community.
Nutzer schöpfen Geld durch Anmeldung einer Leistung, welche von der Community-Verwaltung anerkannt/bestätigt werden muss. Alle Nutzer können einmal geschöpftes Geld untereinander überweisen.

Darüber hinaus hat eine Community Regel nach denen sie funktioniert. Diese Regeln sind in zwei Kategorien aufzuteilen:
- Mathematisch/Logisch prüfbare Regeln
- Informelle/Subjektive Regeln

Mathematisch prüfbare Regeln sind Dinge wie Schöpfungslimit/Zeit, Vergänglichkeit/Zeit oder Geld/Stunde

Informelle Regeln sind z.B. Regularien, wer Mitglied werden darf, welche Leistungen vergütet werden oder welcher Nachweis für eine Leistung erbracht werden muss.
Eine Community hat Nutzer mit verschiedenen Rechten....
Nach Bestätigung der Schöpfung
erhält U3 sein neu geschöpftes Geld
Nach Bestätigung der Schöpfung...
U3
User
U3...
Geldtransfer innerhalb einer Community
Geldtransfer innerhalb einer Community
Da beide Nutzer sich in der selben Community befinden ist ein Geldtransfer zwischen beiden über ihre zentrale Community ohne Umwege möglich
Da beide Nutzer sich in der selben Community befinden is...
Geldschöpfung innerhalb einer Community
Geldschöpfung innerhalb einer Community
Um Geld zu schöpfen meldet ein Nutzer diese bei seiner Community an. Die Community ist hierbei verantwortlich die Regeln der Schöpfung zu definieren. In der Regel wird Arbeitszeit oder bestimmte Tätigkeiten für die Community von einem Mitglied verlangt um eine Schöpfung zu rechtfertigen.

Diese Regeln könnten z.B. die Art der Tätigkeit oder die Menge der abrechnungsfähigen Arbeitszeit betreffen.

Um eine Schöpfung zu vollziehen muss diese, einmal angemeldet, von der Community als gültig/den Regeln entsprechend, bestätigt werden. Hierfür ist die Rolle Trust vorgesehen.
Wer Trust ist bestimmt dabei die Community - so kann das jeder sein - man kann seine eigene Schöpfung bestätigen - oder man darf alle außer der eigenen bestätigen oder ein Teil der Community, bis hin zu nur einem, der bestätigen darf.

Einmal angemeldet und bestätigt wird das Geld erschaffen und vergeht mit einer Vergänglichkeit von x%/Zeit, je nach Community Regeln.
Um Geld zu schöpfen meldet ein Nutzer diese bei seiner C...


A
A...


B
B...


C
C...

Channel
Channel


D
D...
Communities finden
Communities finden
Entgegen der Inner-Community Struktur, welche Hierarchisch organisiert ist, herrscht zwischen mehreren Communities Egalität. D.h. sie kommunizieren auf Augenhöhe - alle sind gleichberechtigt.
Um das zu gewährleisten einigt man sich auf einen "Channel", einen Austauschkanal, der die Kommunikation der Communities sicherstellt. Dieser Kanal dient allerdings nur dazu, dass sich die einzelnen Communities kennen lernen können. Jeder weitere Austausch findet dann direkt zwichen den Communities statt.




Peer-To-Peer Architekturen wie Kademlia leisten es, dasszwei Programme sich unter einem "Topic" finden und sich verbinden können. Dies kommt in Technologien wie BitTorrent zum Einsatz. Dort ist die zu tauschende Datei das "Topic". Man findet sich folglich aufgrund seines "Interesses". Alle mit den gleichen "Interessen"/"Topic" können sich so potentiell finden.

Dieser Prozess ist hier vereinfacht schematisch abgebildet. Der Channel in Verbindung mit einem Topic sorgt dafür, dass sich interessierte Parteien finden.

Um das finden aller Teilnehmer zu verbessern/verschnellern können alle Teilnehmer ihre bekannten Teilnehmer an die anderen propagieren um so beim erkunden des Netzwerkes zu helfen.











Schlussendlich entsteht ein loses Verbindungsnetz zwischen allen teilnehmenden Parteien. Jede Partei hält dabei nur Verbindung zu einer begrenzten Anzahl an Teilnehmern. Zusammen bilden sie aber ein stabiles Netz, welches auch dann weiter besteht, wenn einzelne Knoten/Communities wegfallen.

Grundprinziep ist das Kademlia Netzwerk. Eine moderne Implementierungen ist z.B. HyperSwarm, welches als Library eingesetzt werden kann, um ein solches Netz aufzubauen.

Die Communities tauschen auf diese Weise ihre Adressen aus, folglich wie sie auf direktem Wege erreichbar sind.
Entgegen der Inner-Community Struktur, welche Hierarchis...
Community A lauscht auf Channel
"Geld" und verkündet "Ich bin A"
Community A lauscht auf Channel...


A
A...
Geld
Geld


B
B...
Community B lauscht ebenfalls auf
Channel "Geld" und empfängt die
Nachricht "Ich bin A" von Community A
Community B lauscht ebenfalls auf...
Geld
Geld
B sendet nun über Channel "Geld"
"Hey A, ich bin B".
Damit kennt B A und A B
B sendet nun über Channel "Geld"...


B
B...
Geld
Geld


A
A...


B
B...


C
C...


D
D...


E
E...


F
F...


G
G...


H
H...
Verbindung zwischen Communities
Verbindung zwischen Communities
Haben sich nun zwei solche Communities gefunden findet alle Kommunikation zwischen diesen direkt statt. Sie bauen direkte Verbindung auf.




Um in Kommunikation zu treten bedarf es einer Definition, wie kommuniziert wird. Ein gängiger Weg das modular und algemeingültig zu halten ist zu definieren, welche Protokolle/APIs von der jeweiligen Partei angeboten werden. Die Parteien einigen sich auf ein gemeinsammes Subset an Protokollen/APIs
Haben sich nun zwei solche Communities gefunden findet a...
A baut Direktverbindung zu B auf.
"Hallo B, ich bin A"
A baut Direktverbindung zu B auf....


A
A...


B
B...


B
B...


A
A...
ReceiveMoney
ReceiveMoney
MemberCount
MemberCount
StaticRules
StaticRules
ProsaRules
ProsaRules
B sendet A seine unterstützten Protokolle
B sendet A seine unterstützten...


A
A...


B
B...
 🗸ReceiveMoney
 🗸ReceiveMoney
 🗸MemberCount
 🗸MemberCount
CreationStats
CreationStats
MoneySupply
MoneySupply
A sendet B seine unterstützen Protokolle
A sendet B seine unterstützen P...
inklusive einer Markierung für die Übereinstimmungen
inklusive einer Markierung für die Übere...
Geldtransfer zwischen zwei Communities
Geldtransfer zwischen zwei Communities
Möchten nun zwei Nutzer aus zwei verschiedenen Communities miteinaner handeln, so sind beide Community-Verwaltungen als Mittelmänner beteiligt.
Diese sorgen für den sicheren Transport, den Regel abgleich und die Bewertung der Transaktion.

Hierbei sind verschiedene Modelle denkbar:
1. Die Community entscheidet durch harte Regeln mit wlechen Communities sie Handel erlaubt (Whitelist)
2. Die Community entscheidet mit welchen Communities sie einen Handel nicht zulässt (Blacklist)
3. Die Community weist dem Nutzer ihre Bewertung des Handels aus - z.B. "Du handelst mit einer Community, mit der noch keines unserer Mitglieder gehandelt hat" oder "Die Community scheint andere Schöpfungsregeln zu folgen.
Aber die schlussendliche Entscheidung wird dem Nutzer überlassen.
4. Die Community nimmt eine Transformation vor z.B. Aufgrund der Schöpfungsregeln: C1 schöpft bis zu 1000 Geld pro Monat, C2 bis zu 2000. Bei einem Transfer von C1 nach C2 kann der Betrag mit zwei multipliziert werden, um einen angleich vorzunehmen.

Hierbei ist zu beachten, dass der empfangende Nutzer/Community entscheiden musst, ob er das Geld annimmt, da ein Schwundgeld immer zum Ausgeben anregt.
Der Empfänger entscheidet hierbei immer, ob die Annahme des Zahlungsmittels den aktuellen Wert entwertet und er daher mehr verlangen muss oder den Handel nicht eingeht.
Möchten nun zwei Nutzer aus zwei verschiedenen Communiti...
User5 aus CommunityA möchte
User1 aus CommunityG 15Geld senden
User5 aus CommunityA möchte...
U5:A
U5:A
U1:G
U1:G
1.User5 weißt seine CommunityA an User1
   aus CommunityG 15Geld zu senden
1.User5 weißt seine CommunityA an User1...


A
A...


G
G...
U5:A
U5:A
U1:G
U1:G
2.CommunityA baut eine Direktverbindung
   zu CommunityG auf und übermittelt den
   Wunsch seines User5
2.CommunityA baut eine Direktver...
3.CommunityG fragt seinen User1 ob er das
   Geld von User5:A annehmen möchte
3.CommunityG fragt seinen User1...
4.Nach Bestätigung der Annahme wir
   diese an CommunityA übermittelt.
4.Nach Bestätigung der Annahme w...
5.CommunityA zieht 15 Geld von Users5
   Konto ab und übermittelt diesen
   Vorgang an CommunityG
5.CommunityA zieht 15 Geld von...
6.CommunityG schreibt User1 15 Geld
   auf seinem Konto gut
6.CommunityG schreibt User1 15...
Sicherheit, Vertrauchlichkeit & Privatsphäre
Sicherheit, Vertrauchlichkeit & Privats...
Die notwendige Bestätigung des Empfängers sorgt dafür, dass ein Handel praktisch nur in Echtzeit von Person zu Person stattfinden kann.

Alternativ kann die zu empfangende Zahlung in einem Schwebezustand gehalten werden, bis das Geld voll verfügbar auf dem Konto des Empfänger gutgeschrieben wird. Hier entstünde dann auch eine Prüfungsmöglichkeit und Blockiermöglichkeit für die Empfängercommunity
Die notwendige Bestätigung des Empfängers sorgt dafür, d...
Viewer does not support full SVG 1.1
\ No newline at end of file +
Admin
Admin
Council
Council
User
User
U1 sendet Geld zu U2
U1 sendet Geld zu U2
U1
U1
U2
U2
U4, Ratsmitglied der Community,
bestätigt Schöpfung von U3
U4, Ratsmitglied der Community,...
U4
Council
U4...
U3 meldet eine Schöpfung in
seiner Community an
U3 meldet eine Schöpfung in...
U3
User
U3...
Community
Community
Eine Community hat Nutzer mit verschiedenen Rechten.

Die User können Geldschöpfungen anmelden und Überweisungen tätigen. Der Rat ist der Teil der Nutzer, welche Geldschöpfungen bestätigen können. Administratoren kontrollieren darüber hinaus die nötige Infrastruktur und stehen somit an der Spitze der Kontrolle über die Community.
Nutzer schöpfen Geld durch Anmeldung einer Leistung, welche von der Community-Verwaltung anerkannt/bestätigt werden muss. Alle Nutzer können einmal geschöpftes Geld untereinander frei austauschen.

Darüber hinaus hat eine Community Regel nach denen sie funktioniert. Diese Regeln sind in zwei Kategorien aufzuteilen:
- Mathematisch/Logisch prüfbare Regeln
- Informelle/Subjektive Regeln

Mathematisch prüfbare Regeln sind Dinge wie Schöpfungslimit/Zeit, Vergänglichkeit/Zeit oder Geld/Stunde

Informelle Regeln sind z.B. Regularien, wer Mitglied werden darf, welche Leistungen vergütet werden oder welcher Nachweis für eine Leistung erbracht werden muss.
Eine Community hat Nutzer mit verschiedenen Rechten....
Nach Bestätigung der Schöpfung
erhält U3 sein neu geschöpftes Geld
Nach Bestätigung der Schöpfung...
U3
User
U3...
Geldtransfer innerhalb einer Community
Geldtransfer innerhalb einer Community
Da beide Nutzer sich in der selben Community befinden ist ein Geldtransfer zwischen beiden über ihre zentrale Community ohne Umwege möglich
Da beide Nutzer sich in der selben Community befinden is...
Geldschöpfung innerhalb einer Community
Geldschöpfung innerhalb einer Community
Um Geld zu schöpfen meldet ein Nutzer diese bei seiner Community an. Die Community ist hierbei verantwortlich die Regeln der Schöpfung zu definieren. In der Regel wird Arbeitszeit oder bestimmte Tätigkeiten für die Community von einem Mitglied verlangt um eine Schöpfung zu rechtfertigen.

Diese Regeln könnten z.B. die Art der Tätigkeit oder die Menge der abrechnungsfähigen Arbeitszeit betreffen.

Um eine Schöpfung zu vollziehen muss diese, einmal angemeldet, von der Community als gültig/den Regeln entsprechend, bestätigt werden. Hierfür ist die Rolle Council vorgesehen.
Wer Ratsmitglied ist bestimmt dabei die Community - so kann das jeder sein - man kann seine eigene Schöpfung bestätigen - oder man darf alle außer der eigenen bestätigen oder ein Teil der Community, bis hin zu nur einem, der bestätigen darf.

Einmal angemeldet und bestätigt wird das Geld erschaffen und vergeht mit einer Vergänglichkeit von x%/Zeit, je nach Community Regeln.
Um Geld zu schöpfen meldet ein Nutzer diese bei seiner C...


A
A...


B
B...


C
C...

Channel
Channel


D
D...
Communities finden
Communities finden
Entgegen der Inner-Community Struktur, welche Hierarchisch organisiert ist, herrscht zwischen mehreren Communities Egalität. D.h. sie kommunizieren auf Augenhöhe - alle sind gleichberechtigt.
Um das zu gewährleisten einigt man sich auf einen "Channel", einen Austauschkanal, der die Kommunikation der Communities sicherstellt. Dieser Kanal dient allerdings nur dazu, dass sich die einzelnen Communities kennen lernen können. Jeder weitere Austausch findet dann direkt zwichen den Communities statt.




Peer-To-Peer Architekturen wie Kademlia leisten es, dasszwei Programme sich unter einem "Topic" finden und sich verbinden können. Dies kommt in Technologien wie BitTorrent zum Einsatz. Dort ist die zu tauschende Datei das "Topic". Man findet sich folglich aufgrund seines "Interesses". Alle mit den gleichen "Interessen"/"Topic" können sich so potentiell finden.

Dieser Prozess ist hier vereinfacht schematisch abgebildet. Der Channel in Verbindung mit einem Topic sorgt dafür, dass sich interessierte Parteien finden.

Um das finden aller Teilnehmer zu verbessern/verschnellern können alle Teilnehmer ihre bekannten Teilnehmer an die anderen propagieren um so beim erkunden des Netzwerkes zu helfen.











Schlussendlich entsteht ein loses Verbindungsnetz zwischen allen teilnehmenden Parteien. Jede Partei hält dabei nur Verbindung zu einer begrenzten Anzahl an Teilnehmern. Zusammen bilden sie aber ein stabiles Netz, welches auch dann weiter besteht, wenn einzelne Knoten/Communities wegfallen.

Grundprinziep ist das Kademlia Netzwerk. Eine moderne Implementierungen ist z.B. HyperSwarm, welches als Library eingesetzt werden kann, um ein solches Netz aufzubauen.

Die Communities tauschen auf diese Weise ihre Adressen aus, folglich wie sie auf direktem Wege erreichbar sind.
Entgegen der Inner-Community Struktur, welche Hierarchis...
Community A lauscht auf Channel
"Geld" und verkündet "Ich bin A"
Community A lauscht auf Channel...


A
A...
Geld
Geld


B
B...
Community B lauscht ebenfalls auf
Channel "Geld" und empfängt die
Nachricht "Ich bin A" von Community A
Community B lauscht ebenfalls auf...
Geld
Geld
B sendet nun über Channel "Geld"
"Hey A, ich bin B".
Damit kennt B A und A B
B sendet nun über Channel "Geld"...


B
B...
Geld
Geld


A
A...


B
B...


C
C...


D
D...


E
E...


F
F...


G
G...


H
H...
Verbindung zwischen Communities
Verbindung zwischen Communities
Haben sich nun zwei solche Communities gefunden findet alle Kommunikation zwischen diesen direkt statt. Sie bauen direkte Verbindung auf.




Um in Kommunikation zu treten bedarf es einer Definition, wie kommuniziert wird. Ein gängiger Weg das modular und algemeingültig zu halten ist zu definieren, welche Protokolle/APIs von der jeweiligen Partei angeboten werden. Die Parteien einigen sich auf ein gemeinsammes Subset an Protokollen/APIs
Haben sich nun zwei solche Communities gefunden findet a...
A baut Direktverbindung zu B auf.
"Hallo B, ich bin A"
A baut Direktverbindung zu B auf....


A
A...


B
B...


B
B...


A
A...
ReceiveMoney
ReceiveMoney
MemberCount
MemberCount
StaticRules
StaticRules
ProsaRules
ProsaRules
B sendet A seine unterstützten Protokolle
B sendet A seine unterstützten...


A
A...


B
B...
 🗸ReceiveMoney
 🗸ReceiveMoney
 🗸MemberCount
 🗸MemberCount
CreationStats
CreationStats
MoneySupply
MoneySupply
A sendet B seine unterstützen Protokolle
A sendet B seine unterstützen P...
inklusive einer Markierung für die Übereinstimmungen
inklusive einer Markierung für die Übere...
Geldtransfer zwischen zwei Communities
Geldtransfer zwischen zwei Communities
Möchten nun zwei Nutzer aus zwei verschiedenen Communities miteinaner handeln, so sind beide Community-Verwaltungen als Mittelmänner beteiligt.
Diese sorgen für den sicheren Transport, den Regel abgleich und die Bewertung der Transaktion.

Hierbei sind verschiedene Modelle denkbar:
1. Die Community entscheidet durch harte Regeln mit wlechen Communities sie Handel erlaubt (Whitelist)
2. Die Community entscheidet mit welchen Communities sie einen Handel nicht zulässt (Blacklist)
3. Die Community weist dem Nutzer ihre Bewertung des Handels aus - z.B. "Du handelst mit einer Community, mit der noch keines unserer Mitglieder gehandelt hat" oder "Die Community scheint andere Schöpfungsregeln zu folgen.
Aber die schlussendliche Entscheidung wird dem Nutzer überlassen.
4. Die Community nimmt eine Transformation vor z.B. Aufgrund der Schöpfungsregeln: C1 schöpft bis zu 1000 Geld pro Monat, C2 bis zu 2000. Bei einem Transfer von C1 nach C2 kann der Betrag mit zwei multipliziert werden, um einen angleich vorzunehmen.

Hierbei ist zu beachten, dass der empfangende Nutzer/Community entscheiden musst, ob er das Geld annimmt, da ein Schwundgeld immer zum Ausgeben anregt.
Der Empfänger entscheidet hierbei immer, ob die Annahme des Zahlungsmittels den aktuellen Wert entwertet und er daher mehr verlangen muss oder den Handel nicht eingeht.
Möchten nun zwei Nutzer aus zwei verschiedenen Communiti...
User5 aus CommunityA möchte
User1 aus CommunityG 15Geld senden
User5 aus CommunityA möchte...
U5:A
U5:A
U1:G
U1:G


A
A...


G
G...
U5:A
U5:A
U1:G
U1:G
2.CommunityA baut eine Direktverbindung
zu CommunityG auf und übermittelt den
Wunsch seines User5 und verbucht die
15 Geld als wartend.
2.CommunityA baut eine Direktver...
3.CommunityG fragt seinen User1 ob er das
Geld von User5:A annehmen möchte
3.CommunityG fragt seinen User1...
4.Nach Bestätigung der Annahme wir
diese an CommunityA übermittelt.
4.Nach Bestätigung der Annahme w...
5.CommunityA markiert die Buchung als
ausgeführt und übermittelt dies an
CommunityG und weißt die Buchung
gegenüber dem User5 als ausgeführt.
5.CommunityA markiert die Buchu...
6.CommunityG empfängt die Buchungsbestätigung von CommunityA und schreibt User1 15 Geld auf seinem Konto gut
6.CommunityG empfängt die Buchu...
Sicherheit, Vertrauchlichkeit & Privatsphäre
Sicherheit, Vertrauchlichkeit & Privats...
Die notwendige Bestätigung des Empfängers sorgt dafür, dass ein Handel praktisch nur in Echtzeit von Person zu Person stattfinden kann.

Alternativ kann die zu empfangende Zahlung in einem Schwebezustand gehalten werden, bis das Geld voll verfügbar auf dem Konto des Empfänger gutgeschrieben wird. Hier entstünde dann auch eine Prüfungsmöglichkeit und Blockiermöglichkeit für die Empfängercommunity
Die notwendige Bestätigung des Empfängers sorgt dafür, d...
1.User5 weißt seine CommunityA an User1
   aus CommunityG 15Geld zu senden.
   Das Geld wird von dem Konto des Users
   direkt abgebucht.
1.User5 weißt seine CommunityA a...


A
A...


G
G...
U5:A
U5:A
U1:G
U1:G


A
A...


G
G...
U5:A
U5:A
U1:G
U1:G


A
A...


G
G...
U5:A
U5:A
U1:G
U1:G


A
A...


G
G...
U5:A
U5:A
U1:G
U1:G


A
A...


G
G...
U5:A
U5:A
U1:G
U1:G
Viewer does not support full SVG 1.1
\ No newline at end of file