Kirjoittaja Aihe: Hajautetut Sosiaaliset Verkostot (Diaspora* StatusNet buddycloud Frendica)  (Luettu 7142 kertaa)

Sami Lehtinen

  • Käyttäjä
  • Viestejä: 754
  • Techie
    • Profiili
    • Sami Lehtinen
Olen vuosien ajan näitä tutkinut, mutta koskaan muun kuin RetroSharen käyttäjämäärä ei ole ylittänyt ystäväpiirissä kriittistä massaa. Mitä hyötyjä ja haittoja näette näistä hajautetuista ratkaisuista. Ainakin se ensimmäinen ja suurin hyöty on mielestäni se, että tiedot ovat sinun hallussa, eikä jonkun ylikansallisen vakoiluorganisaation järjestelmissä. Haittana tietenkin on se, että vaaditaan hieman enemmän teknistä osaamista. Tosiaalta, osa näistä ratkaisuista on sellaisia, että riittää että porukassa on yksi pätevä ja hän voi hoitaa palvelun hostauksen kokonaan.

RetroShare tuli otettua käyttöön sähköpostin, skypen ja ftps/sftp saittien korvaajana. Nyt voi suoraan pistää fileet jakoon omalta koneelta ja turvallisesti halutulle joukolle.

StatusNet koittaa ilmeisesti haastaa Twitteriä. Toisaalta, en näe hajautetulla järjestelmällä niinkään suuria hyötyjä mikäli kaikki julkaistu tieto on julkista. Yksityisyys voi kuitenkin pysyä suuriin verrattuna huomattavasti parempana, kun kaikkia palveluita ei ole keskitetty samalla palveluntarjoajalle. Tyyliin, Facebookin ja Googlen (miltei) kaikille sivuille ulottuva vakoilu. Toisaalta nämä vakoilu ja tietoturvaongelmat on myös johtanut selvästi yrityksille suunnattujen kaupallisten palveluiden syntymiseen kuten Microsoftin Yammer.

Diaspora tuntuu lässähtäneen kasaan.

Tent.io ei ole sekään saanut oikein tuulta purjeisiin.

Buddycloud vaikutti mielenkiintoiselta, en kuitenkaan nähnyt mitään hyötyä siinä RetroShareen verrattuna.

Tietysti noiden open source ratkaisuden kanssa joissa hostingin voi hoitaa keskitetysti voisi olla saumaa mm. kansallisen noden / hubin / serverin / podin tai groupin avaamiselle.

Lopuksi vielä linkki Wikipedian vertailuun em. palveluista:
http://en.wikipedia.org/wiki/Comparison_of_software_and_protocols_for_distributed_social_networking

Tässä muutamia linkkejä aikaisempiin keskusteluihin vuosien takaa:
http://forum.ubuntu-fi.org/index.php?topic=39761.0
http://forum.ubuntu-fi.org/index.php?topic=40589.0
http://forum.ubuntu-fi.org/index.php?topic=43542.0
http://forum.ubuntu-fi.org/index.php?topic=35332.0

Toistaiseksi ollaan pärjätty https:n taake pystytetyillä omilla phpbb ratkaisuilla tuon retrosharen lisäksi. Sekä sähköpostin turvaamisella asianmukaista salausta käyttäen.
« Viimeksi muokattu: 09.10.13 - klo:16.59 kirjoittanut Sami Lehtinen »

Beluga

  • Käyttäjä
  • Viestejä: 47
    • Profiili
Olen koordinoimassa Retroshareen uutta käyttöliittymää. Ajatuksena on toteuttaa se QML:llä. Siitä ei ehkä tule virallista, jos RS:n pääkehittäjät epäilevät vakiintuneen käyttäjäkunnan kiivastuvan radikaalista muutoksesta.

Yritin tarjota Friendicaan vastaavaa remonttia, mutta pääkehittäjä Macgirvin lähti ihan haistapaska-linjalle, joten designeri ei oikein innostunut.

Retroshare 0.5 ei tule olemaan yhteensopiva 0.6-version kanssa eli konepellinkin alla tulee radikaalia remppaa. 0.6:stahan on oma haara repossa: http://sourceforge.net/p/retroshare/code/HEAD/tree/branches/v0.6-initdev/

Sellaista tuo RS:n uudelleenmiettimisen parissa puuhasteleva designeri pohti, että mitä jos homma olisi ryhmälähtöinen. Eli luot ryhmän ja kutsut siihen kavereita. Sitten luot ryhmän sisällä foorumeita ja chattiluolia. Mahdollisuudet valita julkisen tai yksityisen väliltä pätisivät edelleen. Oisko tuossa mitään itua? Pyysin häntä tekemään asiasta esityksen ja mielellään graafisten mockuppien kanssa.

Jos Samilla on kiinnostusta jelppiä (esim. käännöksissä) tai kommentoida (ja seurata kehittäjien chattihuonetta), niin minuun voi olla yhteydessä yv:llä.

Sami Lehtinen

  • Käyttäjä
  • Viestejä: 754
  • Techie
    • Profiili
    • Sami Lehtinen
Hmm, kuulostaa että RetroSharessa on samoja haasteita kuin muissakin projekteissa. Tai heh, voisi sanoa melkein kaikissa projekteissa. Sen takia olen avain ehdoton modulaarisuuden, apien ja pluginien kannattaja.

mm. Bitmessagen parissa on ihan samaa vääntöä.

Käyttöliittymät, ominaisuudet, käyttäjien toiveet, käytettävyys ja sitten vielä tiimin resurssit. Ainoa tapa ratkaista noi oikeasti hyvin, on pilkkoa kokonaisuus osiin. Core moduli hoitaa mitä hoitaa ja sen jälkeen mm. käyttöliittymä on jotain, mitä saat ihan vapaasti liimata päälle sellaisena kuin haluat.

Juttelin tuossa erään kaverin kanssa RetroSharesta pitkään ja hartaasti. Hänen näkemyksensä oli suoraan se, että roskaa pukkaavat, koska ei ole mobiilisovellusta. Mikäs tuohon olisi sen parempi ratkaisu kuin että Core ja UI on erityetty. UI modulina voi toimia sitten web-moduli tai vaikka Android / iOS (thin)clientti, jonka jälkeen RetroSharea voi käyttää millä tahansa mobiililaitteella aivan sujuvasti. Core vaan pitää hostata jossain. Tuo tuo myös mahdollisuuksia keskitettyyn palvelutarjontaan, aivan kuten Tent ja Diaspora tms. Eli voi ajaa corea omassa systeemissä, mutta jos luotat palveluntarjoajaan, voit myös ostaa Coren ylläpidon muualta ja käyttää pelkkään ThinClienttiä.

Tuo siis käyttäjille lisää joustavuutta, sekä lisää kehitysresursseja, kun kaikki resurssit ei mene turhaan siihen riitelyyn, että mitähän siihen "mainline" pakettiin nyt tehdään ja mitä ei. Jokainen saa tehdä ihan mitä haluaa, kun käytetään vain yhteisesti sovittuja rajapintoja.

Tuo aivan sama ongelma koskee kyllä myös montaa muuta projektia, joiden parissa olen työskennellyt yli 15 vuotta päivittäin, mitään projekteja nimeämättä. ;) Hirveä sota siitä mitä halutaan tehdä ja mitä ei, vaikka jutuille olisi selvä tilaus. Kuitenkin se joukko joka "saa" tehdä kehitystä on niin rajattu, että muut ei sitä saa tehdä, vaikka haluaisivat. Modulaarisuus, API:t ja Plugarit tuovat tähän ratkaisun, jos vaan se ymmärretään.

Seuraava steppi onkin sitten se, että nuo rajapinnat joiden päälle sitä jatkokehitystä voidaan tehdä, on järkevät, eivätkä ole tehty aivan liian hankalaksi. Taas mitään projekteja nimeämättä. ;)

Toisaalta. mm. Bitmessagen osalta jotkut ovat jo toteuttaneetkin em WEB UI / Hosting ratkaisuita. Onko Retrosharelle mitään vastaavaa tarjolla? En ole tuota kenttää niin kerinnyt seuraamaan.

Tietenkin hostingin myötä tulee se sama ongelma, että luottaako myös MUUT käyttäjät hostingiin. Henkilökohtaisesti olen esimerkiksi sitä mieltä että kaikki gmailin käyttäjät ovat enemmän tai vähemmän luotettavia tyyppejä. Pahinta mitä jotkut voivat tehdä, on mm. se että käyttävät vaikka inet.fi tai kolumbus.fi sähköpostia ja sitten ovat fiksuina laittaneet noista forwarding gmailiin. Mistäpä kukaan siis tietää miten hölmösti dataa käsitellään jatkossa? Toisaalta, mikään näistä ratkaisuista mitkä on mainittu ei ratkaise ns. tyhmien käyttäjien ongelmaa. Koska vaikka käytettäisiin truecryptilä, linuxia, retrosharea, jne. Niin mikään näistä ei takaa, etteikö vastaanottaja tarkoituksella vuotaisi tietoa, tai tahattomasti vuotaisi tietoja eteenpäin vaikka RAT sovelluksen kautta.

mm. Tor käyttäjät eivät ole juuri tästä (TAO/RAT) syystä turvassa, varsinkaan ne hölmömmät Tor käyttäjät jotka eivät tee asioita (oikein) tm.

Monesti olen todennut että tietoturvan ylläpitäminen on melkein (lue käytännässo) mahdotonta. Mikä tahansa kone jota käytetään normaalisti, on äärimmäisen haavoittuva kohdennetuille hyökkäyksille. Vain todella raskas hardening ja tiettyjen policyjen ehdoton noudattaminen tekee koneeseen murtautumisesta merkittävästi vaikeampaa.

Juuri em. syystä mulla on täysin erillinen hardis ja totaalisesti sessioiden välissä resetoitava ympäristö ja käyttöjärjestelmä luottamukselliseen vahvasti salattuun viestintään.

Nämä haluaisivat tehdä selvityksen siitä, onko TrueCrypt turvallinen vai ei. Sitten pitäisi vielä määritellä, mitä turvallinen tarkoittaa ja mitä uhkia kohtaan.

Hyvällä tsägällä sopivasti suunniteltu ratkaisu voisi myös mahdollistaa 3rd party "appliance" markkinat. Eli kaupassa on 30€ maksavat "RS-purkki", riittää että isket sen verkkoon ja ohjaat HTTPS liikenteen sille. Sen jälkeen sulla on oma systeemi pystyssä. Todennäköisesti kauppa tässä tapauksessa tarkoittaisi world wide shipping web-shoppia, mutta silloin volyymi voisi olla juuri ja juuri riittävä muutamalle haxxorille, että hommaa kannattaa pyörittää. Olen ollut juuri tuollaisia ratkaisuita tuotteistamassa, joten voisin hyvin ajatella että tuommosta pystyisi diilaamaan. Ihmisille jotka haluaa hyvän tiimin valmiiksi kasaaman paketin ja päästä helpolla ja vältellä ylläpitokuluja, mutta silti välttää sen, että datat ei ole "jenkkipilvessä". Valmiiksi paketoitu retroshare, hardis (vaikka raspi tai joku muu halpa, johon sopiva muistikortti, nettipäivitykset) jne. Ei kuulosta ollenkaan mahdottomalta idealta.

kw: bitmessage, sähköposit, hajautettu, hosting, palvelu, selaimella, selaimessa, ubuntu, linux, palvelut, palvelu, viestintä, luottamuksellinen, salattu.
« Viimeksi muokattu: 12.10.13 - klo:11.10 kirjoittanut Sami Lehtinen »

Beluga

  • Käyttäjä
  • Viestejä: 47
    • Profiili
Retrosharen no-gui-versio on käsittääkseni nyt ominaisuuksiltaan gui-versiota vastaava. Tämä tarkoittaa, että voimme luoda käyttöliittymiä millä hyvänsä frameworkilla tai systeemillä. Hiljattain kuulin myös, että RS on juurikin siirtymässä kuvailemasi kaltaiseen ratkaisuun, jossa suurin osa ominaisuuksista on plugineja.

Web-käyttis on myöskin työn alla: https://retroshareteam.wordpress.com/2013/08/29/retroshares-web-interface/
Olen ajatellut, että siitä voisi tehdä oman version.

No-gui-versiota on voinut käyttää NAS-laitteissa jo hyvän aikaa: https://retroshareteam.wordpress.com/2013/01/27/using-retroshare-on-the-excito-bubba3/
Itsellänikin on nyt tuo B3, mutta en ole vielä ehtinyt virittää Retrosharea pyörimään siinä.

Android-clienttiä kehitetään myös aktiivisesti: https://github.com/G10h4ck/RetroShare-Android-Client
Android-käyttis voisi myös ratketa Qt 5.2: avulla , jos kykenemme toteuttamaan QML-version käyttiksestä. Qt 5.2:ssä on täysi tuki Androidille ja iOS:lle.

Sami Lehtinen

  • Käyttäjä
  • Viestejä: 754
  • Techie
    • Profiili
    • Sami Lehtinen
Oi nyt täytyy kyllä sanoa että kiitokset. Tuli todellakin aimo pläjäys erittäin hyvää infoa.

 - Kiitos

Pitää vähän tutustua tuohon infoon ja katsoa mitä sitten. Sellainen kysymys vielä asiaan perehtymättä, että tukeeko noi web-clientit ja android clientit, ns. multi-tenant "serveriä". Eli voin hostata omalle pienelle käyttäjäjoukolle kerralla vaikka palvelua ja nämä voivat sitten käyttää vapaasti mm. android / web clienttejä.

Jos toi pelaa, voisi perustaa vaikka ihan harrastuksen nimissä, retroshare hidden servicen Toriin. ;)


Beluga

  • Käyttäjä
  • Viestejä: 47
    • Profiili
Pitää vähän tutustua tuohon infoon ja katsoa mitä sitten. Sellainen kysymys vielä asiaan perehtymättä, että tukeeko noi web-clientit ja android clientit, ns. multi-tenant "serveriä". Eli voin hostata omalle pienelle käyttäjäjoukolle kerralla vaikka palvelua ja nämä voivat sitten käyttää vapaasti mm. android / web clienttejä.

Jos toi pelaa, voisi perustaa vaikka ihan harrastuksen nimissä, retroshare hidden servicen Toriin. ;)

No en keksi muuta kuin että hostaisit palvelimella useita RS:n no-gui:n instansseja, kullekin käyttäjälle omansa. Sitten käyttäjät loisivat android- tai web-clienteissään uuden sijainnin (location), joka on kytköksissä heidän varmenteeseensa. Kysyin devel-chatissa, onko tämä mahdollista ja eräs chattiservereiden parissa puuhasteleva totesi: "of course it is, each with a separate location and/or id. takes a bit of thinking though. perhaps portable for windows, or another login/$HOME/location for linux... " Portable tarkoittaa siis portable-asennusta Winkulle.

Tässä vielä joitakin linkkejä:
Python Retroshare Interface Library (RS:n luojan kehittämä)
Joku uusi jäbä on sitten tehnyt oman versionsa yllämainitusta Haskell-kieltä käyttäen: https://github.com/jacobhinkle/haskell-retroshare
Retroshare-chatserver (dummy-kontakti, jonka avulla pääsee juttelemaan keskusteluauloihin ilman muita kontakteja).
Python irc/retroshare bridge (sama kehittäjä on tehnyt myös tällaisen: TorChat Certificate Exchange for Retroshare)
RetroShare SSH Client

Kohta tulee näköjään uusi pikkupäivitys, jossa on tämmöinen joidenkin kovasti toivoma uusi ominaisuus:
Enabled PFS for SSH connections, based on a 4096 bits safe prime. This is retro-compatible, meaning that old peers will connect to the new one using PFS if they act as a client (meaning they request the connection)

Sami Lehtinen

  • Käyttäjä
  • Viestejä: 754
  • Techie
    • Profiili
    • Sami Lehtinen
No en keksi muuta kuin että hostaisit palvelimella useita RS:n no-gui:n instansseja, kullekin käyttäjälle omansa.

Kuulosta vähän liiankin tutulta. Mulla on valitettavan paljon kokemusta siitä, kun yritetään ajaa "single user" softia kivasti automatisoidussa multi-tenant ympäristössä. On kyllä ihan oman luokan säätämistä, että saa kaiken toimimaan. Multi-tenant ajattelu kun on jotain sellaista, joka on äärimmäisen vaikeaa yleensä pultata jälkikäteen laajaan ohjelmistoon, jonka suunnittelussa ja kehityksessä ei ole lainkaan ajateltu asiaa. Mutta kyllä se toki onnistuu, vaikka ei ole ihan optimi(tm) menetelmä. Been there, done that. Mutta juu, on toimiva ratkaisu ja on toteutettavissa toki myös Linuxilla. Windows serveriä ei jaksa kyllä käytellä, just tässä viikonloppuna päästin mun Windows 2008 R2 Datacenter myllyn eläkkeelle ja sain vanhan Q6600 raudan myytyä.

Valitettavasti tuntuu siltä, että joudun jatkossakin ylläpitämään em. kaltaisia Windows ratkaisuita. ;) Mutta elämäähän se vaan.

Tuollaisissa keisseissä tulee helposti olennaiseksi, kuinka pienellä "aktiivisella" prosessoinnilla prosessi osaa idlata. Eli viekö jokainen idle prosessi paljonkin CPU aikaa ja kuinka suureen määrään muistia viitataan toistuvasti. Ai miksi? No siksi, että vaikka ihmiset väittävät edellen SWAPin olevan pahasta, niin se ei todellakaan ole sitä, niin kauan kuin "aktiivinen datasetti" mahtuu keskusmuistiin. Mulla on pahimmissa esimerkeissä tilanteita joissa muistia on 16 gigaa ja swappia käytössä 64 gigaa. Ei, tämä ei todellakaan tarkoita sitä, että serveri olisi hidas, tai siitä olisi "muisti loppu". Mutta minkäs sille voi kun jokainen prosessi käynnistyessään rohmuaa ensin kauheen kasan muistia, ja sen jälkeen ei tee sillä yhtään mitään. Aivan turhaa sitä on pitää muistissa.

Pythonilla testin sille, miten hyvin käyttis hoitaa swapin ja muistin allokaation tuollaisessa muistipaineen luonnissa ihan helposti.

Suorittamalla nämä kaksi riviä koodia Python varaa gigs parametrin mukaisen määrän muistia gigatavuina.

gigs=32
reserved=1024*1024*1024*gigs*'X'

Tässä koneessa on 32 gigaa swap tilaa ja 32 gigaa RAMia. Tuon suorittaminen kestää muutaman sekunnin ja sen jälkeen ei edes huomaa, että joku prosessi rohmuaa muistia. Mitä sitten? Se varattu muisti johon ei viitata valuu pikkuhiljaa swappiin.

Jees, pitänee jossain vaiheessa tsiigailla tota RetroShare hommaa lisää, jos lisäisin noille parille frendille omat instanssit tohon mun systeemiin. Kun sanoivat että hostaaminen on niin hankalaa ja entäs jos joku heittää relay modessa jotain dataa, joka on vaikka piraattileffa tms. Niin joutuuko "välittäjä" siitä poseen. Jouudin vääntämään rautalangasta, että turtle hoppingin kyllä saa pois päältä tarpeen niin vaatiessa.

Btw. Beluga, oletko muuten sattunut itse tuota Bitmessagea vilkaisemaan? Se on ratkaisu jonka on tarkoitus korvata sähköposti, salatulla mesh networkingillä ja toimii jo, mutta ei nykyisellään skaalaudu.
« Viimeksi muokattu: 13.10.13 - klo:20.24 kirjoittanut Sami Lehtinen »

Beluga

  • Käyttäjä
  • Viestejä: 47
    • Profiili
Kysyin vielä RS:n luojalta ja hän totesi saman, eli useita instansseja samanaikaisesti sekä:
Lainaus
I'd suggest wrapper scripts to launch lots of them.
But you still need PGP keys / passwords for each peer.

Hän totesi, että tässä vaiheessa multitenant-arkkitehtuurin toteuttaminen olisi käytännössä mahdotonta Retrosharessa (sen kummemmin erittelemättä, mutta ehkä kyseessä työvoiman puute?).

Sami Lehtinen

  • Käyttäjä
  • Viestejä: 754
  • Techie
    • Profiili
    • Sami Lehtinen
No siis multi-tenant toteutus jälkikäteen on oikeasti hemmetin ongelmallista. Nimimerkillä, kyseisen tyyppisiin projekteihin olen sotkeutunut tämän pilvi-buumin myötä.

Mut tulee noihin mun testauksiin, kaikki menee ihan hienosti. Mutta CPU aikaa se kuitenkin syö idlellä jopa yllättävän paljon. Ei siis paljon sinänsä yksittäiseksi desktop sovellukseksi ajateltuna, mutta paljon jos ajattelisi ajavan vaikka muutamaa sataa instanssia yhdellä myllyllä, niin sitten toi idle heaviness alkaa näkymään. Muistin kulutus pysyi yllättävän kivasti kurissa 10 - 25 megaa / instanssi, josta suurin osa ei ole aktiivisessa käytössä. Eli ei ole haittaa vaikka rammia olisikin vähemmän kuin instanssit * 25 megaa.

Tuli skriptillä generoitua 100 instanssia tähän mun koneelle ja muistista ei tullut  pulaa, mutta CPU kuormat nousi inhottavasti.

Beluga

  • Käyttäjä
  • Viestejä: 47
    • Profiili
Kokeilitko tätä noguita vai ihan guilla: http://retroshare.sourceforge.net/wiki/index.php/Documentation:retroshare-nogui
Kovotilaa syö cachetukset, mutta niihin pitäisi jeesata, jos käyttää GXS:ää: http://retroshare.sourceforge.net/wiki/index.php/UnixCompile#GXS_related
Toka linkki neuvoo kääntelyt Linuxilla.

Sami Lehtinen

  • Käyttäjä
  • Viestejä: 754
  • Techie
    • Profiili
    • Sami Lehtinen
Kokeilitko tätä noguita vai ihan guilla: http://retroshare.sourceforge.net/wiki/index.php/Documentation:retroshare-nogui

No GUIta tietenkin. Ei kai sitä nyt hostingissa ole mitään järkeä ajaa paikallista käyttöliittymää. ??? Levytilasta viis, sitä kyllä piisaa nykyjään teratavujen aikana.


Sami Lehtinen

  • Käyttäjä
  • Viestejä: 754
  • Techie
    • Profiili
    • Sami Lehtinen
Roadmappia 0.6:een.

Mainiota settiä, kiva nähdä tuollaista kehitystä. Samalla tuo paljastaa sen mitä monessa muussakin systeemissä on havaittu. Se että joku toimii, ei todellakaan tarkoita sitä, että se toimii optimisti. Alkuvaiheessa vaan haetaan yksinkertaista ja helppoa ratkaisua saada joku asia kondikseen, mutta jos se halutaan oikeasti hyvin tiomivaksi, tarvitaan useita refactoring kierroksia ja uudelleen suunnittelua tms, olosuhteiden muuttuessa.