deZentrales OpenSim Netzwerk für Hypergrid

[Sleimer Akina]

Das mit dem dezentralen Ersatz für OpenSimWorld war meine Idee.

Mein absoluter Wunschtraum wäre ja eine dezentrale, föderierte Lösung auf Basis von (streams).

Man wär nicht zwingend abhängig von Admins mit eher zweifelhaften Qualitäten als Community-Keeper, weil es nicht nur das eine zentrale Portal gäbe, sondern viele miteinander vernetzte. Die ganze Sache wär von vornherein im Fediverse (siehe auch Mastodon). Mikrobloggingartiges Posten wär schon von vornherein möglich, Foren/Diskussionsgruppen auch, öffentliche Kalender für Veranstaltungen gäbe es schon von vornherein, Filespace (z. B. für Bilder) gäbe es schon von vornherein. Es bräuchte eigentlich nur etwas oben drauf für OpenSim-Bedarfe.

Find ich aber gut, daß das so prompt aufgegriffen wurde.

Allerdings wär es dafür hilfreich, auch das Fediverse schon einigermaßen zu kennen.

Wenn ich das so lese bei google darüber. Ist ja jeder Nutzer dann ein Server um das mal einfach halber zu erklären. Aber trotzdem untereinander vernetzt.
Dazu müsste man aber zumindest eine Zentrale Basis (Websoftware) aufbauen die aber trotzdem untereinander mit einem zentralen server kommuniziert.
Weil die dezentralen server müssen ja dann sich irgendwie bekannt machen. Und das würde ja nur über eine API schnittstelle gehen die wiederrum mit einem mutter server kommuniziert.

Odet hab ich einen denkfehler? Lasse mich gerne eines besseren belehren

[Jupiter Rowland]

Wenn ich das so lese bei google darüber. Ist ja jeder Nutzer dann ein Server um das mal einfach halber zu erklären. Aber trotzdem untereinander vernetzt.
Dazu müsste man aber zumindest eine Zentrale Basis (Websoftware) aufbauen die aber trotzdem untereinander mit einem zentralen server kommuniziert.
Weil die dezentralen server müssen ja dann sich irgendwie bekannt machen. Und das würde ja nur über eine API schnittstelle gehen die wiederrum mit einem mutter server kommuniziert.

Odet hab ich einen denkfehler? Lasse mich gerne eines besseren belehren

Nein, das sieht ganz anders aus.

Du hast eine Struktur wie bei E-Mail, also lauter einzelne, unabhängige Anbieter. Die sind alle miteinander vernetzt, weil alle auf ihren Servern dieselben Standards und dasselbe Protokoll nutzen. Nur ist es eben nicht E-Mail, sondern z. B. bei Mastodon, Pleroma, Akkoma, MissKey, CalcKey usw. sowas wie Twitter, bei Friendica sowas wie Facebook, bei Pixelfed sowas wie Instagram usw.

So funktioniert doch auch das Hypergrid.

Und das läuft alles, ohne daß alles über irgendeinen zentralen Server oder irgendeine zentrale Serverfarm oder irgendeinen zentralen Knoten laufen muß. Diese Abhängigkeit von irgendwas Zentralem versucht man immer zu verhindern.

Du brauchst nämlich keine zentralen Strukturen, wenn jeder Nutzer auf jeder Instanz jeden Nutzer auf einer anderen Instanz direkt ansprechen kann. Der Trick dabei ist immer derselbe: Du hängst an den Namen des Nutzers den Namen der Instanz dran, meistens getrennt durch ein @. Dann brauchst du keinen Zentralserver, der weiß, wo welcher Nutzer ist, weil die Nutzer es selber wissen.

Beispiel E-Mail: Alice ist bei Gmail, Bob ist bei GMX. Wenn Alice Bob anschreiben will, dann schreibt sie auch nicht an

Code:

Bob

, und irgendein Zentralserver sucht Bob dann raus und findet ihn bei GMX. Sondern sie schreibt direkt an

Code:

Bob@gmx.de

. Dann kann die Mail direkt von Gmail, wo Alice ist, zu GMX gehen, wo Bob ist.

Bei XMPP ist das so. Bei Matrix ist das so, auch wenn das Adreßformat ein anderes ist. Im Hypergrid in OpenSim ist das so.

Im Fediverse ist das auch so, aber noch extremer, weil du Dutzende und Dutzende verschiedene Projekte hast, die alle miteinander sprechen, und nicht nur eins, wie viele Mastodon-Leute glauben. Es gibt im wesentlichen eine gemeinsame Sprache, ActivityPub, und so können alle Leute auf allen Instanzen bei allen Projekten miteinander kommunizieren. Innerhalb der Projekte natürlich auch. Allenfalls die Entwicklung der jeweiligen Projekte ist jeweils zentralisiert, aber das ist auch alles frei und quelloffen, und einige Projekte werden schon von ihrer eigenen Community gepflegt.

Bogus Curry ist z. B. auf Mastodon, das wird ja seit letztem Jahr als die Twitter-Alternative überhaupt gehypet. Pius Noel auch, aber auf einer anderen Instanz. Die können miteinander kommunizieren ohne irgendeinen Zentralserver für alle. Ich bin auf Hubzilla, aber ich kann auch mit beiden kommunizieren. Hubzilla spricht ActivityPub als "Fremdsprache", aber es spricht ActivityPub, also können Hubzilla-Instanzen sich mit Mastodon-Instanzen verbinden.

Was ich mir jetzt als Basis für einen OSW-Ersatz überlegt hab, ist ein Code-Repository namens Streams. Das wird gerne auch (streams) geschrieben, weil das kein in sich geschlossenes Produkt mit feststehender Marke ist wie Mastodon oder Pleroma oder Pixelfed oder Friendica oder Hubzilla usw., sondern es ist als Bastelkasten gedacht. Im Prinzip ist es ein Fork von einem Fork von einem Fork von Hubzilla, aber die Forks sind alle auch vom Macher von Hubzilla. Gegenüber Hubzilla ist es noch moderner und gründlich entschlackt, weil es eben kein Alleskönner out of the box mehr sein muß.

Man muß bei (streams) allerdings mit den Lizenzen aufpassen: Das ist absichtlich unter einen ganzen Salat von freien Lizenzen gestellt worden. Das meiste ist in der Public Domain, aber andere Teile stehen unter allen möglichen freien Lizenzen. Man kann aus (streams) also nichts Unfreies bauen, was unter Copyright steht und closed-source ist; da wird man immer gegen irgendeine Lizenz verstoßen. Wenn allerdings das Endergebnis genauso frei und quelloffen bleibt, ist alles gut.

[Sleimer Akina]

Wenn ich das so lese bei google darüber. Ist ja jeder Nutzer dann ein Server um das mal einfach halber zu erklären. Aber trotzdem untereinander vernetzt.
Dazu müsste man aber zumindest eine Zentrale Basis (Websoftware) aufbauen die aber trotzdem untereinander mit einem zentralen server kommuniziert.
Weil die dezentralen server müssen ja dann sich irgendwie bekannt machen. Und das würde ja nur über eine API schnittstelle gehen die wiederrum mit einem mutter server kommuniziert.

Odet hab ich einen denkfehler? Lasse mich gerne eines besseren belehren

Nein, das sieht ganz anders aus.

Du hast eine Struktur wie bei E-Mail, also lauter einzelne, unabhängige Anbieter. Die sind alle miteinander vernetzt, weil alle auf ihren Servern dieselben Standards und dasselbe Protokoll nutzen. Nur ist es eben nicht E-Mail, sondern z. B. bei Mastodon, Pleroma, Akkoma, MissKey, CalcKey usw. sowas wie Twitter, bei Friendica sowas wie Facebook, bei Pixelfed sowas wie Instagram usw.

So funktioniert doch auch das Hypergrid.

Und das läuft alles, ohne daß alles über irgendeinen zentralen Server oder irgendeine zentrale Serverfarm oder irgendeinen zentralen Knoten laufen muß. Diese Abhängigkeit von irgendwas Zentralem versucht man immer zu verhindern.

Du brauchst nämlich keine zentralen Strukturen, wenn jeder Nutzer auf jeder Instanz jeden Nutzer auf einer anderen Instanz direkt ansprechen kann. Der Trick dabei ist immer derselbe: Du hängst an den Namen des Nutzers den Namen der Instanz dran, meistens getrennt durch ein @. Dann brauchst du keinen Zentralserver, der weiß, wo welcher Nutzer ist, weil die Nutzer es selber wissen.

Beispiel E-Mail: Alice ist bei Gmail, Bob ist bei GMX. Wenn Alice Bob anschreiben will, dann schreibt sie auch nicht an

Code:

Bob

, und irgendein Zentralserver sucht Bob dann raus und findet ihn bei GMX. Sondern sie schreibt direkt an

Code:

Bob@gmx.de

. Dann kann die Mail direkt von Gmail, wo Alice ist, zu GMX gehen, wo Bob ist.

Bei XMPP ist das so. Bei Matrix ist das so, auch wenn das Adreßformat ein anderes ist. Im Hypergrid in OpenSim ist das so.

Im Fediverse ist das auch so, aber noch extremer, weil du Dutzende und Dutzende verschiedene Projekte hast, die alle miteinander sprechen, und nicht nur eins, wie viele Mastodon-Leute glauben. Es gibt im wesentlichen eine gemeinsame Sprache, ActivityPub, und so können alle Leute auf allen Instanzen bei allen Projekten miteinander kommunizieren. Innerhalb der Projekte natürlich auch. Allenfalls die Entwicklung der jeweiligen Projekte ist jeweils zentralisiert, aber das ist auch alles frei und quelloffen, und einige Projekte werden schon von ihrer eigenen Community gepflegt.

Bogus Curry ist z. B. auf Mastodon, das wird ja seit letztem Jahr als die Twitter-Alternative überhaupt gehypet. Pius Noel auch, aber auf einer anderen Instanz. Die können miteinander kommunizieren ohne irgendeinen Zentralserver für alle. Ich bin auf Hubzilla, aber ich kann auch mit beiden kommunizieren. Hubzilla spricht ActivityPub als "Fremdsprache", aber es spricht ActivityPub, also können Hubzilla-Instanzen sich mit Mastodon-Instanzen verbinden.

Was ich mir jetzt als Basis für einen OSW-Ersatz überlegt hab, ist ein Code-Repository namens Streams. Das wird gerne auch (streams) geschrieben, weil das kein in sich geschlossenes Produkt mit feststehender Marke ist wie Mastodon oder Pleroma oder Pixelfed oder Friendica oder Hubzilla usw., sondern es ist als Bastelkasten gedacht. Im Prinzip ist es ein Fork von einem Fork von einem Fork von Hubzilla, aber die Forks sind alle auch vom Macher von Hubzilla. Gegenüber Hubzilla ist es noch moderner und gründlich entschlackt, weil es eben kein Alleskönner out of the box mehr sein muß.

Man muß bei (streams) allerdings mit den Lizenzen aufpassen: Das ist absichtlich unter einen ganzen Salat von freien Lizenzen gestellt worden. Das meiste ist in der Public Domain, aber andere Teile stehen unter allen möglichen freien Lizenzen. Man kann aus (streams) also nichts Unfreies bauen, was unter Copyright steht und closed-source ist; da wird man immer gegen irgendeine Lizenz verstoßen. Wenn allerdings das Endergebnis genauso frei und quelloffen bleibt, ist alles gut.

Hey, danke für deine Ausführliche Erklärung, aber was ich noch nicht stehe wie soll man sich dann untereinander bekannt machen? Wenn Grid A ein dezentrales system und Grid B müssen die ja in der samtheit sich austauschen können, so das es zu einer Indexierung kommt. Weil woher soll Grid A wissen wie Grid B heisst? Ich hoffe du verstehdt was ich meine.
Deswegen hab ich eine API ins spiel gebracht die genau das tut. Sie veröffentlich zentral in datenbank bestimmte ingormationen.
Wenn jeder betreiber aber wiederrum ein eigenes system sagen wir seite/script was auch immer am laufen hat. Hat man ja wieder das problem das man ständig zu dessen internetseite muss. Wobei viele auch garkeine homepage haben.

Dann wird das mit dem dezentralen system wieder nicht so einfach.

Eine einfache Indexierung würde ich da bevorzugen. Man hat einen Indexer dienst der das macht.
Da kann man infos über dad grid durchlesen. Hat ein Profilkarte z.b welche sim was anbietet wo man vielleicht artikel eindtellen kann, und man mit tp in den inworld shop kommt.

[Gubbly]

Wenn ich das so lese bei google darüber. Ist ja jeder Nutzer dann ein Server um das mal einfach halber zu erklären. Aber trotzdem untereinander vernetzt.
Dazu müsste man aber zumindest eine Zentrale Basis (Websoftware) aufbauen die aber trotzdem untereinander mit einem zentralen server kommuniziert.
Weil die dezentralen server müssen ja dann sich irgendwie bekannt machen. Und das würde ja nur über eine API schnittstelle gehen die wiederrum mit einem mutter server kommuniziert.

Odet hab ich einen denkfehler? Lasse mich gerne eines besseren belehren

Nein, das sieht ganz anders aus.

Du hast eine Struktur wie bei E-Mail, also lauter einzelne, unabhängige Anbieter. Die sind alle miteinander vernetzt, weil alle auf ihren Servern dieselben Standards und dasselbe Protokoll nutzen. Nur ist es eben nicht E-Mail, sondern z. B. bei Mastodon, Pleroma, Akkoma, MissKey, CalcKey usw. sowas wie Twitter, bei Friendica sowas wie Facebook, bei Pixelfed sowas wie Instagram usw.

So funktioniert doch auch das Hypergrid.

Und das läuft alles, ohne daß alles über irgendeinen zentralen Server oder irgendeine zentrale Serverfarm oder irgendeinen zentralen Knoten laufen muß. Diese Abhängigkeit von irgendwas Zentralem versucht man immer zu verhindern.

Du brauchst nämlich keine zentralen Strukturen, wenn jeder Nutzer auf jeder Instanz jeden Nutzer auf einer anderen Instanz direkt ansprechen kann. Der Trick dabei ist immer derselbe: Du hängst an den Namen des Nutzers den Namen der Instanz dran, meistens getrennt durch ein @. Dann brauchst du keinen Zentralserver, der weiß, wo welcher Nutzer ist, weil die Nutzer es selber wissen.

Beispiel E-Mail: Alice ist bei Gmail, Bob ist bei GMX. Wenn Alice Bob anschreiben will, dann schreibt sie auch nicht an

Code:

Bob

, und irgendein Zentralserver sucht Bob dann raus und findet ihn bei GMX. Sondern sie schreibt direkt an

Code:

Bob@gmx.de

. Dann kann die Mail direkt von Gmail, wo Alice ist, zu GMX gehen, wo Bob ist.

Bei XMPP ist das so. Bei Matrix ist das so, auch wenn das Adreßformat ein anderes ist. Im Hypergrid in OpenSim ist das so.

Im Fediverse ist das auch so, aber noch extremer, weil du Dutzende und Dutzende verschiedene Projekte hast, die alle miteinander sprechen, und nicht nur eins, wie viele Mastodon-Leute glauben. Es gibt im wesentlichen eine gemeinsame Sprache, ActivityPub, und so können alle Leute auf allen Instanzen bei allen Projekten miteinander kommunizieren. Innerhalb der Projekte natürlich auch. Allenfalls die Entwicklung der jeweiligen Projekte ist jeweils zentralisiert, aber das ist auch alles frei und quelloffen, und einige Projekte werden schon von ihrer eigenen Community gepflegt.

Bogus Curry ist z. B. auf Mastodon, das wird ja seit letztem Jahr als die Twitter-Alternative überhaupt gehypet. Pius Noel auch, aber auf einer anderen Instanz. Die können miteinander kommunizieren ohne irgendeinen Zentralserver für alle. Ich bin auf Hubzilla, aber ich kann auch mit beiden kommunizieren. Hubzilla spricht ActivityPub als "Fremdsprache", aber es spricht ActivityPub, also können Hubzilla-Instanzen sich mit Mastodon-Instanzen verbinden.

Was ich mir jetzt als Basis für einen OSW-Ersatz überlegt hab, ist ein Code-Repository namens Streams. Das wird gerne auch (streams) geschrieben, weil das kein in sich geschlossenes Produkt mit feststehender Marke ist wie Mastodon oder Pleroma oder Pixelfed oder Friendica oder Hubzilla usw., sondern es ist als Bastelkasten gedacht. Im Prinzip ist es ein Fork von einem Fork von einem Fork von Hubzilla, aber die Forks sind alle auch vom Macher von Hubzilla. Gegenüber Hubzilla ist es noch moderner und gründlich entschlackt, weil es eben kein Alleskönner out of the box mehr sein muß.

Man muß bei (streams) allerdings mit den Lizenzen aufpassen: Das ist absichtlich unter einen ganzen Salat von freien Lizenzen gestellt worden. Das meiste ist in der Public Domain, aber andere Teile stehen unter allen möglichen freien Lizenzen. Man kann aus (streams) also nichts Unfreies bauen, was unter Copyright steht und closed-source ist; da wird man immer gegen irgendeine Lizenz verstoßen. Wenn allerdings das Endergebnis genauso frei und quelloffen bleibt, ist alles gut.

Hey, danke für deine Ausführliche Erklärung, aber was ich noch nicht stehe wie soll man sich dann untereinander bekannt machen? Wenn Grid A ein dezentrales system und Grid B müssen die ja in der samtheit sich austauschen können, so das es zu einer Indexierung kommt. Weil woher soll Grid A wissen wie Grid B heisst? Ich hoffe du verstehdt was ich meine.
Deswegen hab ich eine API ins spiel gebracht die genau das tut. Sie veröffentlich zentral in datenbank bestimmte ingormationen.
Wenn jeder betreiber aber wiederrum ein eigenes system sagen wir seite/script was auch immer am laufen hat. Hat man ja wieder das problem das man ständig zu dessen internetseite muss. Wobei viele auch garkeine homepage haben.

Dann wird das mit dem dezentralen system wieder nicht so einfach.

Eine einfache Indexierung würde ich da bevorzugen. Man hat einen Indexer dienst der das macht.
Da kann man infos über dad grid durchlesen. Hat ein Profilkarte z.b welche sim was anbietet wo man vielleicht artikel eindtellen kann, und man mit tp in den inworld shop kommt.

Das ist ganz einfach. Jede Instance führt eine Liste, mit ihm bekannten anderen Instancen. Bei dem ersten Kontakt von einer Instance zur anderen, nehmen beide Instancen die jeweils andere in ihre Listen mit auf und teilen sich diese Liste regelmäßig.
So bekommt jede Instance früher oder später Kontakt zu jeder anderen Instance, die öffentlich verfügbar ist.

Das ganze setzt dann vorraus, dass eine Instance Manuell hinzugefügt wird.

[Jupiter Rowland]

Hey, danke für deine Ausführliche Erklärung, aber was ich noch nicht stehe wie soll man sich dann untereinander bekannt machen? Wenn Grid A ein dezentrales system und Grid B müssen die ja in der samtheit sich austauschen können, so das es zu einer Indexierung kommt. Weil woher soll Grid A wissen wie Grid B heisst? Ich hoffe du verstehdt was ich meine.
Deswegen hab ich eine API ins spiel gebracht die genau das tut. Sie veröffentlich zentral in datenbank bestimmte ingormationen.
Wenn jeder betreiber aber wiederrum ein eigenes system sagen wir seite/script was auch immer am laufen hat. Hat man ja wieder das problem das man ständig zu dessen internetseite muss. Wobei viele auch garkeine homepage haben.

Dann wird das mit dem dezentralen system wieder nicht so einfach.

Eine einfache Indexierung würde ich da bevorzugen. Man hat einen Indexer dienst der das macht.
Da kann man infos über dad grid durchlesen. Hat ein Profilkarte z.b welche sim was anbietet wo man vielleicht artikel eindtellen kann, und man mit tp in den inworld shop kommt.

Das ist ganz einfach. Jede Instance führt eine Liste, mit ihm bekannten anderen Instancen. Bei dem ersten Kontakt von einer Instance zur anderen, nehmen beide Instancen die jeweils andere in ihre Listen mit auf und teilen sich diese Liste regelmäßig.
So bekommt jede Instance früher oder später Kontakt zu jeder anderen Instance, die öffentlich verfügbar ist.

Das ganze setzt dann vorraus, dass eine Instance Manuell hinzugefügt wird.

Manuell muß da überhaupt nichts eingetragen werden.

Sagen wir, wir haben zwei Instanzen, InstanzA und InstanzB.

Ich bin auf InstanzA, also Jupiter@InstanzA.

Jetzt will ich Sleimer, der auf InstanzB ist, eine Message schicken. Also adressiere ich die an Sleimer@InstanzB.

Daher weiß meine Instanz:
a) Es gibt InstanzB.
b) Sleimer ist auf InstanzB, also muß da auch die Message hin.

Es braucht keine wie auch immer geartete Zentrale, die InstanzA sagt, daß es InstanzB und da einen Sleimer gibt. Daß es InstanzB gibt, weiß InstanzA daher, weil ich da eine Message hinschicken will, also muß es diese Instanz wohl geben. Und daß es auf InstanzB einen Sleimer gibt, weiß InstanzA daher, daß die Message an ihn auf InstanzB gehen soll.

Spätestens in dem Augenblick, wo meine Message bei Sleimer ankommt, weiß InstanzB auch, daß es InstanzA gibt, weil von da ja gerade eine Message gekommen ist.

Das Fediverse läuft übrigens seit 2008 ohne jegliche Zentrale. 100% dezentral. E-Mail läuft schon sehr viel länger 100% dezentral.

[Sleimer Akina]

Hey, danke für deine Ausführliche Erklärung, aber was ich noch nicht stehe wie soll man sich dann untereinander bekannt machen? Wenn Grid A ein dezentrales system und Grid B müssen die ja in der samtheit sich austauschen können, so das es zu einer Indexierung kommt. Weil woher soll Grid A wissen wie Grid B heisst? Ich hoffe du verstehdt was ich meine.
Deswegen hab ich eine API ins spiel gebracht die genau das tut. Sie veröffentlich zentral in datenbank bestimmte ingormationen.
Wenn jeder betreiber aber wiederrum ein eigenes system sagen wir seite/script was auch immer am laufen hat. Hat man ja wieder das problem das man ständig zu dessen internetseite muss. Wobei viele auch garkeine homepage haben.

Dann wird das mit dem dezentralen system wieder nicht so einfach.

Eine einfache Indexierung würde ich da bevorzugen. Man hat einen Indexer dienst der das macht.
Da kann man infos über dad grid durchlesen. Hat ein Profilkarte z.b welche sim was anbietet wo man vielleicht artikel eindtellen kann, und man mit tp in den inworld shop kommt.

Das ist ganz einfach. Jede Instance führt eine Liste, mit ihm bekannten anderen Instancen. Bei dem ersten Kontakt von einer Instance zur anderen, nehmen beide Instancen die jeweils andere in ihre Listen mit auf und teilen sich diese Liste regelmäßig.
So bekommt jede Instance früher oder später Kontakt zu jeder anderen Instance, die öffentlich verfügbar ist.

Das ganze setzt dann vorraus, dass eine Instance Manuell hinzugefügt wird.

Manuell muß da überhaupt nichts eingetragen werden.

Sagen wir, wir haben zwei Instanzen, InstanzA und InstanzB.

Ich bin auf InstanzA, also Jupiter@InstanzA.

Jetzt will ich Sleimer, der auf InstanzB ist, eine Message schicken. Also adressiere ich die an Sleimer@InstanzB.

Daher weiß meine Instanz:
a) Es gibt InstanzB.
b) Sleimer ist auf InstanzB, also muß da auch die Message hin.

Es braucht keine wie auch immer geartete Zentrale, die InstanzA sagt, daß es InstanzB und da einen Sleimer gibt. Daß es InstanzB gibt, weiß InstanzA daher, weil ich da eine Message hinschicken will, also muß es diese Instanz wohl geben. Und daß es auf InstanzB einen Sleimer gibt, weiß InstanzA daher, daß die Message an ihn auf InstanzB gehen soll.

Spätestens in dem Augenblick, wo meine Message bei Sleimer ankommt, weiß InstanzB auch, daß es InstanzA gibt, weil von da ja gerade eine Message gekommen ist.

Das Fediverse läuft übrigens seit 2008 ohne jegliche Zentrale. 100% dezentral. E-Mail läuft schon sehr viel länger 100% dezentral.

Ja gut und schön, wenn ich InstanceB schreiben will muss ich vorher wissen wie sie heisst.

Opensim ist nichts anderes wie ein Fediverse System nur dann bräuchte es kein system art telefonbuch.
Weil bringen tut mir das nichts, wenn ich die gegenadresse nicht weiss kann ich da auch nicht hinschreiben mal als beispiel.
Deswegen find ich brauch eine art Zentrales Telefonbuch wo sich die leute eintragen lasseb können. Somit wird das grid auch bekannt.

Weil so wäre das keine brauchbare lösung.
Woher soll ich dann wissen das ob es einen nutzer gibt mit einer SIMxyz.

Ich hoffe ich hab mich so weit verständlich ausgedrückt.

[Anachron]

...
Woher soll ich dann wissen das ob es einen nutzer gibt mit einer SIMxyz.
...

Da hat er ein Argument, wir können zwar z.B. aus der Tatsache, dass aus einem Grid ABC ein Besucher irgendwo registriert wird auf die Existenz des Grids schliessen, aber welche SIMs es dort gibt, wissen wir damit noch nicht ... es gibt dort sicher eine Default-StartSIM, aber damit lässt sich allenfalls ein Gridkatalog ermitteln, aber nicht ein Katalog von interessanten Teleportzielen.

Was ich an der bisherigen Diskussion aber auf jeden Fall als Konsens entnehme, ist eins:
Was wir nicht brauchen ist ein Ranking irgendeiner Art.

[Sleimer Akina]

...
Woher soll ich dann wissen das ob es einen nutzer gibt mit einer SIMxyz.
...

Da hat er ein Argument, wir können zwar z.B. aus der Tatsache, dass aus einem Grid ABC ein Besucher irgendwo registriert wird auf die Existenz des Grids schliessen, aber welche SIMs es dort gibt, wissen wir damit noch nicht ... es gibt dort sicher eine Default-StartSIM, aber damit lässt sich allenfalls ein Gridkatalog ermitteln, aber nicht ein Katalog von interessanten Teleportzielen.

Was ich an der bisherigen Diskussion aber auf jeden Fall als Konsens entnehme, ist eins:
Was wir nicht brauchen ist ein Ranking irgendeiner Art.

Nein da hast du recht, das hab ich von vorherein schon komplett ausgeschlossen. Wie schon erwähnte würde ich interesssnt finden ein Travel Katalog, mit verschiedenen Zielen. Meinet wegen auch Kategoriesiert, und eventuell das die betroffene sim bzw. Das Regionsprofil eine kleine shop seite hat, aber nicht im großen stil einfach nur wo man vielleicht bildern und text was hinterlegen kann fertig vesuchen muss man den shop dann schon vorort.
Und durch suchen, z.b Shoes oder so zeigt er regionen an die schuhe anbieten.
So das ganze könnte man soweit machen, das wenn man sich eh inworld befindet, nicht extra auf die seite müsste, sondern die inworld suche nutzen könnte dafür.
Und auch bei Firestorm könnte man die Destination URL mit nutzen. Was das ganze richtig geil machen würde.
So brauch man auch beacon oder sonst was.
Und damit die Grids übersichtlich bleiben wird alle 14 Tage geprüft mit einem ping z.b ist Region A noch da wenn ja alles gut. Wenn nicht löschen aus dee liste. Somit bleibt das system immer selber aktuell und es fallen keine tote grid mit rein

[Bogus Curry]

Hallo zusammen ;D

Ich weiss nicht ob das umsetzbar ist, was ich im kopf hab, aber wie wäre es, wenn man so ein Art Bilderwand hätte und wenn man auf die Bilderwand klickt, kommt man zu dem Ort. Im HIntergrund könnte man dann halt per hand oder halt auch automatisch Adressen auslesen, de man in ein Script gibt, wo halt die Teleportadresse drin steht.

Dazu könnte man vielleicht ein Menü erstellen, wo man intressante Orte von dem Grid aufgezählt werden, das man besuchen will. Dieses würde ich aber er nachhinein einbinden, erstmal müsste eine Art Grundstruktur erstellt werden. Programmiertechnisch kann ich leder nichts beitragen, ausser mich als TestObjekt bzw. User bereitstellen ;D

ja, ich höre schon den einen oder anderen stöhnen, was soll denn das, kann man doch nicht umsetzen. Lasst uns doch erstmal hier alle Vorschläge sammeln, was dann umsetzbar ist und was nicht, kann man ja im nachhinein ja schaun ;D

[Dorena Verne]

Bilderwand? Wie wäre es hier als Unterbereich von Gridtalk sowas zum Anklicken.