Laverna: Gabelung laverna

Erstellt am 6. Aug. 2018  ·  19Kommentare  ·  Quelle: Laverna/laverna

Da PRs nicht mehr genehmigt werden, denke ich, dass es an der Zeit ist, dieses Projekt entweder abzuspalten oder es für etwas aufzugeben, das regelmäßig gewartet wird.

Ich überlege, dies zu tun, da ich bereits einige der gemeldeten Fehler in meinem Entwicklungszweig behoben habe. Ich bin jedoch kaum ein JS-Experte, also wenn jemand anderes daran interessiert ist, zu helfen, wäre das gut.

Sollten wir den Namen ändern, um Verwechslungen zu vermeiden? Wenn ja, irgendwelche Namensvorschläge?

Hilfreichster Kommentar

Also hat sich wwebfor bei mir gemeldet. Er ist fertig mit dem Projekt.

Er räumte ein, dass laverna Probleme mit der Synchronisation und mehreren Geräten nicht löst. Er schlug vor, dass die Bemühungen besser darauf verwendet werden sollten, sich auf andere Projekte zu konzentrieren, die dies bereits tun. Er hat mir auch keinen Zugriff auf das Repo gegeben, also kann ich nichts direkt damit machen.

Ich denke, seine Bedenken sind berechtigt, aber ich mag Laverna und ich denke, es lohnt sich, etwas daraus zu machen. Ich werde meinen Plan fortsetzen, es zu forken und unabhängig von der laverna-Organisation weiterzuentwickeln.

Ich habe die letzten Wochen damit verbracht, mich mit dem Dev-Zweig vertraut zu machen und an kleineren Fehlern zu arbeiten, wo ich konnte. Es ist ehrlich gesagt gerade nicht in einem sehr guten Zustand:

  • Es sieht so aus, als ob das Projekt mitten im Übergang zu einem Client/Server-Modell mit dem Hinzufügen des Signalservers und mongodb war. Das ist nicht unbedingt ein schlechtes Modell für das Hosting, aber es wird für Standalone-Endbenutzer, die über Dropbox synchronisieren (oder überhaupt nicht), mühsam.
  • Der Signalserver scheint mit Blick auf eine Mehrbenutzerumgebung zusammengestellt worden zu sein, und es gibt den Anfang einiger nützlicher Funktionen (wie die gemeinsame Nutzung zwischen Benutzern), aber das ist unvollständig, und ich glaube, dass derzeit die Synchronisierung über mehrere Geräte hinweg verhindert wird.
  • Trotzdem ist https standardmäßig nicht aktiviert.
  • Die elektronenbasierte Desktop-App-Version funktioniert nicht.
  • gulp ist in Knoten 10 aufgrund alter Abhängigkeiten ziemlich kaputt. Angeblich wird dies eines Tages behoben, obwohl der aktuelle Plan zu sein scheint, eine neuere Version des natives-Pakets zu erzwingen, die nicht unterstützt wird. Ich konnte keine ETA finden.

Ich würde gerne mehr über diese Probleme sprechen und Empfehlungen / Hilfe zu deren Behebung erhalten. Ich werde dieses Problem auf meinem Fork unter https://github.com/daed/laverna/issues/1 replizieren

Ich ermutige jeden, der ein berechtigtes Interesse an dem Projekt verspürt, nachdrücklich, zu diskutieren, und ich möchte alle anderen warnen, dass dieses Projekt, wie es bei der Laverna-Organisation existiert, wahrscheinlich nicht weiter aktualisiert wird.

Alle 19 Kommentare

Ich habe einen anständigen Programmierhintergrund, aber ich lerne gerade js und bin bereit, mich bei Bedarf zu bemühen, um zu diesem Projekt beizutragen, da es seit langem meine Goto-App ist. Was den Namen Laverna2.0 angeht... Heh.

@daed Versuchen wir zuerst @wwebfor && @wwwredfish zu schreiben.

Ich bin mir ziemlich sicher, dass sie alle Mitwirkenden oder Sie zur Organisation hinzufügen können, damit Sie Schreibzugriff haben...
Ansonsten lass es mich wissen, wenn du einen Namen und eine Veröffentlichung hast, damit ich das AUR-Paket erstellen kann :wink:

Können Sie mich über keybase (bevorzugt) oder kontaktieren , damit ich Ihnen später heute (Berliner Zeit) die persönliche E-Mail von

PS: Wenn Sie neue Versionen auf Ihrem Fork generieren, kann es eine gute Idee sein, auch Tarballs zu generieren :smile:

Ja sicher. Ich wollte das Projekt niemandem entreißen. Ich wollte nur sicherstellen, dass es nicht zurückbleibt.

Ich bin in der zentralen US-Zeit. Ich spreche morgen mit Ihnen über die Schlüsselbasis, wenn ich kann.

Also hat sich wwebfor bei mir gemeldet. Er ist fertig mit dem Projekt.

Er räumte ein, dass laverna Probleme mit der Synchronisation und mehreren Geräten nicht löst. Er schlug vor, dass die Bemühungen besser darauf verwendet werden sollten, sich auf andere Projekte zu konzentrieren, die dies bereits tun. Er hat mir auch keinen Zugriff auf das Repo gegeben, also kann ich nichts direkt damit machen.

Ich denke, seine Bedenken sind berechtigt, aber ich mag Laverna und ich denke, es lohnt sich, etwas daraus zu machen. Ich werde meinen Plan fortsetzen, es zu forken und unabhängig von der laverna-Organisation weiterzuentwickeln.

Ich habe die letzten Wochen damit verbracht, mich mit dem Dev-Zweig vertraut zu machen und an kleineren Fehlern zu arbeiten, wo ich konnte. Es ist ehrlich gesagt gerade nicht in einem sehr guten Zustand:

  • Es sieht so aus, als ob das Projekt mitten im Übergang zu einem Client/Server-Modell mit dem Hinzufügen des Signalservers und mongodb war. Das ist nicht unbedingt ein schlechtes Modell für das Hosting, aber es wird für Standalone-Endbenutzer, die über Dropbox synchronisieren (oder überhaupt nicht), mühsam.
  • Der Signalserver scheint mit Blick auf eine Mehrbenutzerumgebung zusammengestellt worden zu sein, und es gibt den Anfang einiger nützlicher Funktionen (wie die gemeinsame Nutzung zwischen Benutzern), aber das ist unvollständig, und ich glaube, dass derzeit die Synchronisierung über mehrere Geräte hinweg verhindert wird.
  • Trotzdem ist https standardmäßig nicht aktiviert.
  • Die elektronenbasierte Desktop-App-Version funktioniert nicht.
  • gulp ist in Knoten 10 aufgrund alter Abhängigkeiten ziemlich kaputt. Angeblich wird dies eines Tages behoben, obwohl der aktuelle Plan zu sein scheint, eine neuere Version des natives-Pakets zu erzwingen, die nicht unterstützt wird. Ich konnte keine ETA finden.

Ich würde gerne mehr über diese Probleme sprechen und Empfehlungen / Hilfe zu deren Behebung erhalten. Ich werde dieses Problem auf meinem Fork unter https://github.com/daed/laverna/issues/1 replizieren

Ich ermutige jeden, der ein berechtigtes Interesse an dem Projekt verspürt, nachdrücklich, zu diskutieren, und ich möchte alle anderen warnen, dass dieses Projekt, wie es bei der Laverna-Organisation existiert, wahrscheinlich nicht weiter aktualisiert wird.

Schöne Zusammenfassung @daed :tada: :star:

Ich bin dabei!

Als Referenz: #931

Hi.
Früher habe ich Laverna betrieben und wegen DropBox aufgegeben. Meine 2 Cent: Zu einem echten Client/Server-Modell mit einem Datenbank-Back-End zu gehen, könnte gut sein, um viele Synchronisierungsprobleme zu vermeiden. Und das macht das Projekt fast unabhängig.

@romu70 Das ist eines der Dinge, mit denen ich mich auseinandergesetzt habe. Aus irgendeinem Grund hatte ich nie die Probleme mit der Dropbox-Synchronisierung, über die sich alle beschweren, und ich mag die Tatsache, dass es keinen zentralen Server gibt. Die Dropbox-Methode ist ähnlich, aber ich kann mir zumindest meine Notizen ansehen und sehen, dass sie verschlüsselt sind. Wenn eine Person oder eine Gruppe Eigentümer der Software und der Datenbank ist, beispielsweise innerhalb eines Client/Server-Modells, löst dies viele der notwendigen Kopfschmerzen, aber wie beweisen Sie, dass Ihre Daten wirklich richtig geschützt sind? Eine öffentliche API, auf die Sie bereits verschlüsselte Nachrichten pushen können, wäre ein solcher Weg, aber das ist der weit entfernteste Weg.

Ich habe mit dem Versuch herumgespielt, einen Weg zu finden, um es mit einer gehosteten Version, einer Bring Your Own Server-Version und einer eigenständigen Desktop-Version nach Belieben bereitzustellen, aber das klingt so, als würde es unglaublich schwierig sein, es zu unterstützen.

Ich glaube, dass der Client/Server wirklich der schnellste und wahrscheinlichste Weg zum nächsten Release ist, aber je weiter wir uns darauf zubewegen, desto schwieriger wird es, eine eigenständige Desktop-Anwendung zu implementieren.

Ich neige dazu, zuzustimmen. Client/Server ist gut, wenn Sie daran denken, dass Ihr Produkt auf Benutzerservern installiert wird. Auf diese Weise sind Sie ziemlich sicher, dass die Daten privat sind, aber die Einrichtung ist sicherlich weniger einfach.

Was die Desktop-Anwendung betrifft, bin ich mir nicht sicher, ob dies die Dinge schwieriger macht. Denken Sie nur daran, das Frontend mit Electron zu packen, und Sie sind fast fertig.

Ich bin beeindruckt zu sehen, dass Leute, die diese Codebasis nicht kennen, bereit sind, darin zu graben. Aber man kann auch über einen einfacheren Weg gehen, zu Boostnote gehen, das bereits dasselbe bietet (DropBox-Sync), mit einer bereits gut gepflegten Codebasis, Community, Support usw.

Das Leben ist zu kurz, um das Rad neu zu erfinden.

Boostnote ist ziemlich glatt, dem stimme ich zu. Es ist viel weiter und hat noch viel mehr Glanz. Es handhabt jedoch keine Verschlüsselung (die Funktionsanforderung ist seit knapp einem Jahr offen), und der Fußabdruck dessen, was auf einem Computer installiert werden muss, scheint viel schwerer zu sein als Laverna.

Laverna kann auch komplett von USB genutzt werden und trotzdem mit Dropbox interagieren, auch wenn es nicht installiert ist. Das ist auch ziemlich ordentlich. Ich denke, es lohnt sich hier viel zu sparen, selbst angesichts anderer Notiztools mit mehr Ressourcen als ein paar fixierten Leuten.

Ein einfacher Benutzer hier, aber das Hauptmerkmal von Laverna ist die Zero-Knowledge-Verschlüsselung mit dem Slogan "Behalten Sie Ihre Notizen privat". Ohne das könnte ich genauso gut zu Evernote zurückkehren.

Okay, die Elektronenimplementierung des Laverna-Frontends war viel einfacher zu implementieren, als ich dachte, dass es für den Entwicklungszweig wäre. Es braucht immer noch (funktionierende) automatisierte Build-Tools, aber es ist ein Schritt in die richtige Richtung.

@glocalglocal Was ist deine Definition von "privat"?

Gilt "verschlüsselt, aber auf einem Server, der Ihnen nicht gehört" als "privat"?
Was ist mit "verschlüsselt, aber auf Ihrer lokalen Festplatte"?

Ich schätze, auf Umwegen frage ich, ob das erste gut genug ist oder ob das zweite eine Voraussetzung ist, um die Software für die Verwendung in Betracht zu ziehen? Keine falschen Antworten; Ich brauche hier die Benutzerperspektive.

Auswahl ist immer gut. Es wird sich also definitiv lohnen, dieses Projekt zu forcieren, obwohl es andere ausgereifte Alternativen gibt.

Folgendes ist meiner Meinung nach zunächst der flexibelste und wartungsfreundlichste Kompromiss:

Derzeit in der Entwicklung:
Laverna besteht aus zwei Komponenten, drei, wenn Sie die Benutzeroberfläche zählen, vier, wenn Sie mongodb zählen (derzeit eine Voraussetzung). Das ist eine unvernünftige Erwartung an einen Benutzer. Die benutzerseitige Komponente kommuniziert mit einem Signalserver, der wiederum mit mongodb kommuniziert. Derzeit speichert mongodb nur Benutzernamen und meiner Meinung nach öffentliche Schlüssel. Alles, was der Signalserver tut (was mir bekannt ist), ist die Datenbank von der Komponente zu entkoppeln, die die Benutzeroberfläche verarbeitet. Dies bedeutet, dass es für einen Benutzer möglich wäre, eine laverna "gui" (Laverna in Elektron als Beispiel) auszuführen und sich mit einem öffentlichen laverna "server" / db zu verbinden. Die Multi-User / Multi-Device-Implementierung sieht nach meinen flüchtigen Tests jedoch unvollständig aus. Wenn es irgendwie vollständig ist, konnte ich nicht herausfinden, wie man es benutzt, was bedeutet, dass es wahrscheinlich viel zu kompliziert ist.

Was ich für Entwickler vorschlage:
Wir führen den Signalserver und die Benutzeroberfläche zu einem Paket zusammen. Darüber hinaus erstellen wir Elektronenversionen dieses zusammengeführten Pakets. Wir verarbeiten alle Daten über den Signalserver an die Datenbank. Notizen, Notizbücher, Backup-Konfigurationsdateien, alles außer dem privaten Schlüssel. Wir enthalten eine Konfiguration, mit der Sie eine Benutzeroberfläche, einen Signalserver oder beides starten können. Außerdem bauen wir einen Adapter für den Signalserver, um sqlite3-Verbindungen verarbeiten zu können.

Dies nimmt laverna und lässt Sie es in alles verwandeln, was Sie wollen. Die drei offensichtlichen Konfigurationen mit diesem Schema, aus denen Sie eine der folgenden auswählen können:

  1. vollständig verwaltet: UI, Signalserver und Datenbank laufen alle auf einem Server irgendwo. Sie verbinden sich über den Browser. Das ist im Grunde mehr oder weniger das, was laverna.cc heute ist. Sie erhalten den größten Komfort und müssen nichts herunterladen / installieren, haben aber die geringste Transparenz und müssen Ihrem Serveradministrator blind vertrauen. Ich werde dies die "Evernote-Konfiguration" nennen.
  2. Client / Server: UI läuft auf Client-Computer über Knoten oder Elektron, Signalserver und Datenbank laufen irgendwo auf einem Server. Sie verfügen über einen zentralisierten Speicher und verfügen über alle Funktionen für die Zusammenarbeit, die möglicherweise auf der ganzen Linie enthalten sind, und Sie besitzen den UI-Client, den Sie aus der Quelle erstellen können, um eine angemessene Erwartung zu haben, dass die Sicherheit auf Client-Ebene aufrechterhalten wird. Dies ist wahrscheinlich der beste Kompromiss aus Funktionen, Komfort und Sicherheit. Dies ähnelt vage, wie ich die Funktionsweise von Keybase verstehe.
  3. völlig eigenständig: UI, Signalserver und Datenbank laufen alle auf einer Box. Knoten oder Elektron starten die Benutzeroberfläche und den Signalserver für Sie, wenn Sie sie ausführen. Datenbank ist Ihre Wahl von mongodb oder wenn Sie die einfache Option ohne zusätzliche Installation wünschen, können Sie sqlite3 wählen. Wir entleeren die Dropbox-API-Methode vollständig und gehen zur Dropbox-Synchronisierung über das Dateisystem. Wenn Sie möchten, dass Dropbox synchronisiert wird, können Sie die Datenbank im Dropbox-Verzeichnis unter einem beliebigen Pfad ablegen. Wenn Sie möchten, dass Ihre Notizen auf ein Flash-Laufwerk oder NFS oder /dev/null geschrieben werden, weisen Sie es einfach an. Dies ist wahrscheinlich das, was der aktuellen Version von laverna im Moment am nächsten kommt.

Beachten Sie, dass ich "client" und "ui" oben austauschbar verwende.

Meine einzige wirkliche Sorge ist die Robustheit von sqlite3, insbesondere bei der Synchronisierung über Dropbox. Ich habe eine Ahnung (und nur eine Ahnung), dass die meisten Synchronisierungsprobleme, die Leute mit Dropbox hatten, API-bezogen sind, und der einfache Wechsel zur App / zum Dateisystem für den Dropbox-Zugriff wird viele dieser Schmerzen heilen.

Das ist viel zu besprechen, und ich bin wahrscheinlich nicht der beste, um meine Gedanken zu erklären, aber Fragen? Anliegen? Kommentare?

@daed aus Benutzersicht, solange die Verschlüsselung stark genug und transparent ist, kann die DB überall gespeichert werden und das würde für mich keine Datenschutzbedenken aufwerfen.

Ich würde das Client/Server-Modell (2) mit seinen Open-Source-Desktop- und mobilen Clients zur Prüfung/Überprüfung und Serverspeicher für Portabilität und Teilbarkeit bevorzugen. Häufig bieten Anwendungen das Standalone-Modell (3) als Option an. Könnte nicht auch die lokale Kopie der Datenbank in Modell 2 optional in einem Dropbox-, MEGA- usw. Ordner gespeichert werden? Das würde auch funktionieren, wenn der Server für immer verschwindet.

Löst die clientseitige Verschlüsselung/Entschlüsselung bei Modell (1) das Vertrauensproblem nicht? zB Lastpass, Bitwarden. Das setzt voraus, dass das, was im Browser ausgeführt wird, überprüft wird. Modell (1) wäre unter bestimmten Umständen praktisch.

Für Modell 1:
Der „Client“ ist in diesem Fall nur ein „dummer“ Webbrowser, der eine Verbindung zur laverna-UI herstellt. Das gibt uns zwei Möglichkeiten.

  • Wir können den Benutzer entweder nach dem Pfad zu seinem privaten Schlüssel fragen, damit wir ihn (lokal) lesen und die Krypto in browserseitigem js ausführen können, bevor wir die Nachricht an die Knoteninstanz weitergeben, auf der die laverna ui läuft, was unpraktisch ist es erfordert lokale Dateien, die den Zweck eines vollständig gehosteten Setups zunichte machen. Dies wäre ähnlich wie die Funktionsweise von github, aber github hat technisch gesehen noch einen Client mit git/ssh.
  • Oder wir können den Server Ihren privaten Schlüssel aufbewahren/verwalten lassen (aber NIEMALS Ihre Passphrase) und dann erledigen wir die Dinge zu 100% aus der Ferne. Sie könnten Ihren privaten Schlüssel herunterladen/ändern, aber Sie müssen auch darauf vertrauen, dass wir die Passphrase nicht aufbewahren und dass wir die Sicherheit Ihres Schlüssels nicht vermasseln. Dies ist meiner Meinung nach näher an der Implementierung. Dies ist im Grunde genommen kostenloses Evernote mit freundlicheren ToS und einer Wohlfühl-Open-Source-Atmosphäre. Nicht ideal, könnte aber für manche ausreichend sein.

Es könnte mehr Optionen geben, aber ich bin mir nicht sicher, was sie zu diesem Zeitpunkt sein würden. Lastpass / Bitwarden Passwörter speichern und verschleiern, dachte ich. Dies ist eine Verschlüsselungsfunktion, die in Verbindung damit verwendet werden könnte, aber sie löst nicht das Problem der Schlüsselverwaltung. Ich habe beides noch nie verwendet, daher ist es möglich, dass ich ihren Nutzen nicht vollständig verstehe.
Abgesehen davon werde ich wahrscheinlich einen "offiziellen" Server wie diesen auf AWS oder so einrichten, nur für den Fall, dass das für einige Leute, wenn nicht alle, gut genug ist. Ich könnte mir vorstellen, dass kostenloses Evernote auch mit einigen Vertrauensproblemen für einige Benutzer mehr als ausreichend ist. Vielleicht einen Spenden-Button draufschlagen und sehen, ob ich jemals die Hosting-Kosten wieder hereinbekomme.

Für Modell 2:
Dies ist eigentlich meine Lieblingsimplementierung der drei möglichen. Technisch muss noch null Software auf dem Computer installiert werden. Sie können laverna von einem USB-Laufwerk ausführen und Ihren Schlüssel dort aufbewahren. Sie könnten es sogar in ein USB-Laufwerk mit darauf installierten Schwänzen einbetten, wenn Sie für öffentliche Computer so weit gehen wollten.
Ich hatte keine lokale Kopie in Betracht gezogen, aber eine Art Notiz-Import/Export/Backup-Funktion stand auf meiner Liste, also passen beide gut zusammen. Wenn Ihr Server nicht mehr funktioniert, können Sie einfach zu Modell 3 wechseln, die Notizen importieren und weitermachen, als ob nichts passiert wäre. Es mag ein wenig seltsam sein, von in mongodb gespeicherten Daten in ein lokales Format zu wechseln, aber das ist wahrscheinlich etwas, mit dem man umgehen kann.

Als allgemeines Update habe ich gestern Abend eine Proof-of-Concept-Elektronen-App erstellt, in die die Benutzeroberfläche und der Signalserver eingebettet sind und beide beim Start gestartet werden. Ganz ohne Politur und völlig untauglich für eine Veröffentlichung, aber es hat mir gezeigt, dass es mit sehr geringem Mehraufwand zu 100% möglich war, noch Model 3 zu haben.

Ich denke, wenn wir mit dem 3-Modell-Schema gehen, werde ich Pakete für eine "Server" -Version erstellen, die die Laverna-UI und das Server-Zeug und kein Elektron enthält, sowie eine "Client" -Version, die auch die Komponenten für alles enthält als Elektron. Für die Serverversion muss die Konfiguration durch Bearbeiten von Dateien erfolgen, sie kann jedoch serverseitige Komponenten für Modell 1 oder Modell 2 bereitstellen, während die Clientversion über eine UI-Konfigurationsseite/einen Assistenten verfügt und in der Lage ist, bereitzustellen Komponenten für den Kunden für Modell 2 sowie die vollständige Modell-3-Implementierung.


Dieses Gespräch war hilfreich, aber es ist nicht besonders hilfreich, bei diesem Laverna-Repo zu bleiben, da ich damit nichts anfangen kann. Ich werde hier immer noch nachsehen, ob jemand etwas Neues postet, aber wenn Sie weiter darüber sprechen möchten (und ich hoffe, dass alle das tun!), würde ich darum bitten, dass wir dies bei mir unter https://github.com/daed . tun

Und danke an alle.

Ich weiß nicht, was Forking bedeutet (und ich bin mir nicht sicher, ob ich das tun sollte?), aber trotzdem; Ich habe die laverna apk ausprobiert und es scheint, dass die Synchronisierung damit nicht funktioniert. Ich habe es mit 5storage versucht. Es scheint eine andere Android-Version auf einer anderen Seite zu geben, aber keine Version, muss sie erstellen und mit meinem schlechten Wissen ist es einfach fehlgeschlagen.

@xreqx Es bedeutet, dass das Projekt tot ist und ich den Code nehme und selbst wieder

Die mobile Version habe ich mir ehrlich gesagt noch nicht angeschaut. Um ehrlich zu sein, habe ich keine Erfahrung mit dem Schreiben von mobilen Anwendungen. Es ist etwas, das ich gerne arbeiten würde.

Erwähnenswert ist die Standarddatei ; die Bibliothek, die von Standardnotizen verwendet wird .

Standard File ist eine Synchronisierungs- und Verschlüsselungsbibliothek für Web- und native Anwendungen. Es ermöglicht Entwicklern, sich auf die Entwicklung großartiger benutzerorientierter Anwendungen zu konzentrieren, und überlässt die Synchronisierung, Server und End-to-End-Verschlüsselung dieser Bibliothek.
..
Standard File ist ein wiederverwendbares Client- und Serversystem, mit dem Sie einen "dummen" Backend-Server bereitstellen können, der Ihr Datenschema nicht kennt oder sich darum kümmert, und es Ihnen ermöglicht, Daten auf der Clientseite zu verschlüsseln und mit dem Remote-Server zu synchronisieren .

Also hat sich wwebfor bei mir gemeldet. Er ist fertig mit dem Projekt.

Beachten Sie, dass ich diese Wikipage vor einiger Zeit erstellt habe. Ich habe deinen Kommentar verlinkt:
https://github.com/Laverna/laverna/wiki/DEAD-PROJECT-ALERT

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

Aaron-Zhao picture Aaron-Zhao  ·  5Kommentare

fanrongqitiancai picture fanrongqitiancai  ·  8Kommentare

nicolas-raoul picture nicolas-raoul  ·  5Kommentare

InviteCiel picture InviteCiel  ·  3Kommentare

hgaronfolo picture hgaronfolo  ·  5Kommentare