Moin @afrog, ich würde nach wie vor keine PHP-Lösung für das Signieren der Transaktionen verwenden. Die Hauptgründe sind folgende:
Wie kommst du mit PHP an den Active-Key (und alle anderen) eines Users, wenn man Keys grundsätzlich nicht an Server überträgt oder dort speichert? Das würde viele Sicherheitsprobleme von vornherein mit sich bringen, die du mit Javascript nicht hättest (signiert wird im Browser und nur das Ergebnis nämlich die signierten Daten werden rausgeschickt). Im Optimalfall sollte eine Website gar keinen Zugriff auf private Schlüssel haben, was man ganz einfach mit KeyChain oder zur Not auch SteemConnect erreichen kann.
Wäre mir zu aufwändig. Bedenke, dass du sowieso mit JS arbeiten musst und mit PHP jede Benutzeraktion an den Server schicken und das Ergebnis danach wieder auswerten müsstest, um eventuelle Meldungen, Status der Aktion usw. anzuzeigen. Was du größtenteils mit einer einzigen Programmiersprache und direkt im Browser erledigen könntest, würdest du auf mehrere Sprachen verteilen.
Bzgl. des Editors kann ich dir so auf die Schnelle auch keine richtige Antwort geben. Mal eben den Steemit-Condenser (der übrigens auf React.js läuft) bei dir reinzufriemeln, halte ich für schwierig bis unmöglich.
Wahrscheinlich wäre der Vue Editor die bessere und vor allem umsetzbarere Lösung, allerdings musst du dann vermutlich das Vue.js Framework bei jedem Seitenaufruf laden. Ob der Editor nicht erlaubte HTML-Tags und Attribute rausfiltert, damit keine XSS-Attacken gestartet werden können, weiß ich nicht. Ich gehe aber davon aus, da er von Buildteam entwickelt wird, die immer sehr gute Qualität abliefern. (Will es nur gesagt haben, weil ich keine Zeit habe das zu prüfen und nichts empfehlen möchte, was ich noch nicht selbst getestet habe).
Moinsen @chriddi und @steemchiller.
Danke für deinen Kommentar zu meinem Hilfeschrei, @chriddi. Es wäre durchaus wünschenswert, wären weitere Entwickler an dem Gegenstand interessiert. Schließlich gehören sie zu einer der gefragtesten Zielgruppen des SteemWiki. Danke @steemchiller, du hast mir schon wieder elementare Denkansätze vermittelt. Ich versuche, das hier vor gemischtem Publikum zu rekapitulieren, zu erweitern, bzw. zu diskutieren. Das dient dem tieferen Verständnis bei jedem Beteiligten, geht es hier doch um die Essenz von Funktionen und ihren Libraries. Worüber ich zur Findung einer verbindlichen Architektur komme. Daher wage ich, dich kurz weiter zu beanspruchen, Chiller.
Der Umgang mit den Schlüsseln ist unsere Archillesferse. Manche Prozesse wollen den Posting Key, manche brauchen den Active Key, usw.. Wir wollen unsere Schlüssel aber nicht durch das Internet zu einem Node schicken, nur damit dort ein Server klärt, ob auf die Blockchain geschreiben werden darf, oder nicht. Oder ob wir für die Info berechtigt sind, die angefordert wurde. Bei PHP geht das ausschließlich über Versenden des Schlüssels, was der Beliebigkeit sehr nahe kommt, sicherheitstechnisch überspitzt ausgedrückt. Ferner hast du keine Ahnung, was der Empfänger-Node (dnode,ist eine Maschine, Software und ein Betreiber) mit deinem Schlüssel noch veranstaltet. Auf dem Wege begibst du dich in vertrauenswürdige Hände, was einem Ausgeliefertsein entspricht. Es gibt daher mindestens zwei Argumente gegen den Einsatz von PHP-Libraries, bei der Kommunikation mit der Blockchain.
Keine Schlüssel senden
Das ist das eine Problem und die Chiller-Methode ist mit JS-Abfragen eindeutig im Vorteil. Eine gewünschte Transaktion ruht dabei so lange im lokalen Browsercache, bis dem wartenden Clearingprozess der richtige Schlüssel vorliegt. Dem Dienst an der JS-API des Servers ist es dabei gleich, was der User darf und was nicht. Deine Berechtigung wird lokal geklärt, vorher kannst du die Daten nicht anrühren. Du bräuchtest Hacker-Methoden, sie zu lesen, bzw. ausführen zu lassen. Ohne Schlüssel ist das nahezu unmöglich. Wir schicken ausschließlich Nutzdaten über das Netz und keine Schlüssel. An denen hängt bekanntlich alles Glück und Gut der Miner, wie auch für jeden Steem-Autoren sein Copyright. Man könnte JS daher zum Dogma erheben.
B) Geschwindigkeit und PHP
Es würde sich im Falle eines PHP-Nodes um den sogenannten dnode handeln, auf dem eine dnode-Library den Verkehr regelt. Die wird abgefragt von einem dnode Client (User). Nach dem Prinzip hatte @jesta seine genialen Steemtools in PHP entwickelt. Unvergessen die Zeit, die sie bei der Ausführung in Anspruch nahmen! Deren Haupteinsatz ist in 2016/17 zu verorten, also lange vor dem Auftauchen von Chillers lockeren Javascriptmethoden. Jestas Tools waren die einzige Quelle für tiefergehende Bockchainabfragen. Dafür gab es keine, oder nur unzulängliche Steemit-Methoden. Die Steemtools waren vor allem sehr langsam. Erinnert ihr euch?
Javascript vs. PHP?
Das erkläre mal auf diplomatischen Weg einer Kultur, für die Javascript der Beelzebub ist und wo der Chef nach der besten PHP-Library fragt. JS gilt als unsicher nicht parallel genug (es arbeitet strikt sequenziell) und ist selbst von Script-deppen wie mir zu benutzen. Ich frage mich wiederholt, warum ein Frosch so einen Stoff überhaupt andenken muss, aber es ist seine Vision und seine Aufgabe, sein Tiki durchzuziehen. Solange kein Besserer am Thema arbeitet muss er eben ran. Sag an, lieber @steemchiller: Habe ich das gerade richtig rekapituliert?
Es gibt Bedenken
Nach meinen Informationen hat Jesta den eigenen dnode abgeschaltet. @dragosroua entwickelt sein PHP nicht weiter und überhaupt, die angebotenen Libraries sind alle alt bis auf die Lösungen, wo überwiegend statistische Daten von der Blockchain verarbeitet werden. Wie das mit der sicher tollen PHP-Library von @t3ran13 der Fall ist. Ansonsten tut sich bei der Entwicklung von PHP-Libraries derzeit nicht viel und die schlüsselhöheren Abfragen, bzw Aufträge müssen eventuell sogar über sie ausgeführt (Coin-Transfer etc.) werden. Da weiß ich noch zu wenig. Nach meinem Glauben geht nahezu alles auch über die JS-API. Arbeitest du an solchen Stellen mit PHP, Chiller? Das Fachgespräch ist für mich noch nicht zuende,
Die Wand
Die PHP-Leute glauben nicht an die Harmlosigkeit von JS. Sie trauen Javascript nicht über den Weg und Firmen lassen gar Javascript netzwerkweit abschalten. Das ist Fakt. Wir haben eine Diskrepanz zwischen bspw. Redaktionen und privaten Anwendern, die man nicht einfach vom Tisch wischen kann. Danach entsteht ein Zusammenhang mit den Zielen des Tikis, der eindeutig für den Einsatz von PHP spricht. Will doch das SteemWiki die Brücke von der Blockchain zu den Unternehmen der Medienbranche schlagen.
Muss ich in dem Fall einen Steem SQL-Node betreiben, wie du das ja auch tust, Chiller? Firmen wollen kein Javascript und hier beißt sich die Schlange in den Schwanz. Oder etwa nicht? Redaktionen müssen ihren Content massenweise und geordnet auf die Blockchain bringen. JS geht bei denen nicht. Mit welcher Library geht das am besten? Ich überlege, ob nicht ein Transfer vom PHP der Unternehmensrechner zum JS der API im Tiki selbst statt finden kann. Corporated PHP wird vom Tiki als API-Javascript weiter gegeben und umgekehrt. Wäre das ein Ansatz?
thx to google
It is correct, but! php for backend, js for frontend.
If you display post - php, if you send something to blockchain - js.
Hi @t3ran13. Nice to read you in my blog. I will take your PHP library into my Steem-plattform-solution. Maybe I have to complete your library with some additional pushs and calls, but your good work will do the main part and one day it will be part of the Steem-option in Tiki 20.0. I showed Marc Laporte (head of Tiki.org) your library and he said "Super!".
I am developing on the platform of a great software-suite, called Tiki (19.1). The craziest thing is: I never developed anything – except my bankrupcy, 20 years before. I like your statistics very much, you know. Most people doesn't know how genious your approach works at all. Only less people know, how good it is but go on, Sir. Perseverance is conducive. I will inform always about our progress and you are able to read about in our publications on @steemwiki.
Now I'm thinking about, how to present your reputation on my Startpage, when you lookup a Steemians avatar there. See you! Thank you for your kind attention and the comment. Thats it! On frontend JS – and PHP on the backend!
Bye @t3ran13. Hope to see you again, soon in my blogs. Stay cool and keep on truckin'.
It is great and thank you!
You can always ask if i can help)
I have to thank you so much, @t3ran13. One good library and one to ask. I am very proud for your kind offer. I'm pretty sure there will be things to ask. Let's do it here, or in the @steemwiki's blog. Anyway. You will be voted, at least.
Ride on, your statistics are great, Are you interested in an accout of SteemWiki?