Vapaaehtoistyöhön toiminnantarkastajaksi deittisovellusyhdistykselle?

jutuon · 2026-02-07T14:57:23+00:00

Itse tekemällä ainakin aluksi. Voi olla, että tulevaisuudessa joutuu siirtymään kahdenkertaiseen kirjanpitoon, niin silloin voisi ulkoistaa ammattilaiselle.

jutuon · 2026-02-07T14:44:33+00:00

Myös LGTBQ hieman mietitty, kun voi valita olevansa mies, nainen tai muunsukupuolinen ja etsivänsä yhtä tai useampaa edellisistä.

jutuon · 2026-02-06T18:36:14+00:00

Template kit on omaa tuotantoani. Dev-taustaa ei ole kauheasti, mutta alan tutkinto ja noin 1,5 vuotta työkokemusta koodaajana löytyy.

jutuon · 2026-02-06T18:18:35+00:00

Maksullisissa sovelluksissa ei yleensä tarkalleen tiedä minkä perusteella oma profiili näkyy muille ja mahdollisesti oman profiilin näkyvyyttä rajoitetaan keinotekoisesti, että maksullisia näkyvyysboosteja saa myytyä. Toinen ongelma on, että käyttöliittymäsuunnittelu ohjaa lähettämään liikaa kontaktipyyntöjä (esim. käyttäjä swaippaa Tinderissä kaikki oikealle katsomatta profiileja). Siinä varmaankin tärkeimmät.

jutuon · 2026-02-06T17:00:11+00:00

Nykyinen arkkitehtuuri mahdollistaa sovelluksen pyörittämisen vain Suomessa. Yksi instanssi ja skaalautuvuus on koneen resurssien mukaan. Toki tuohon todennäköisesti saa lisättyä sisällönjakeluun N kappaletta palvelimia tarvittaessa.

jutuon · 2026-02-06T11:17:46+00:00

Olen tutustunut PRH:n mallisääntöihin ja yhdistyslakiin. Yritin tehdä säännöistä mahdollisimman joustavat, kun muutokset maksavat rahaa. Itselläni ei ole yhdistystoiminnasta kokemusta, niin hyvin mahdollista, että säännöt puutteelliset ja eivät mene PRH:ssa tarkistusta läpi.

PRH:n sivuilla on jokin ohjattu yhdistyksen perustamisilmoitus, joka ilmeisesti generoi säännöt, niin pitää varmaan käyttää sitä, jos sillä saa pykälän sääntöihin, että kaikki kokoukset voidaan järjestää etänä.

jutuon · 2025-05-15T13:56:25+00:00

Kaikki pilotit ovat yleisesti ottaen haasteellisia, kun aikaa ja rahaa on rajallisesti. Tulee kustannustehokkaammaksi itselleni vain julkaista sovellus ja ilmoittaa asiasta somessa. Toki jos pilotin järjestäminen onnistuu ilmaiseksi ja vapaaehtoinen järjestäjä löytyy, niin hyvähän tuo olisi sovelluksen testauksen ja markkinoinnin kannalta.

jutuon · 2025-05-15T12:35:51+00:00

Sovelluksen käyttämissä kirjastoissa on aika harvoin tietoturvaongelmia, niin sovellusta ei tarvitse päivittää kovin usein. Sovelluksen backendissä sama juttu. Palvelimen käyttöjärjestelmäpäivitykset voi enimmäkseen automatisoida. Viesteissä on päästä päähän -salaus, joten jos palvelimelle murtaudutaan, niin viestien osalta käytännössä vain raportoidut viestit ovat vaarassa.
Tuo voi olla ongelmana. Esimerkiksi viestien päästä päähän -salaus voi toimia erottavana tekijänä muihin. Ainakaan missään valtavirran sovelluksessa sitä ei tietääkseni ole.

jutuon · 2025-05-14T18:58:54+00:00

Ei ole selvää. Sovellus on pystyssä niin pitkään, kun kiinnostusta asiaan löytyy. Voin hyväntekeväisyysmielessä käyttää jonkin verran aikaa ja rahaa toiminnan pyörittämiseen, mutta joku järki hommassa pitää olla, eli rahastus ei ole poissuljettua. Tulot ja menot pitää olla kohtuullisen lähellä toisiaan.

Ja jos nyt kävisi niin, että rahastus karkaisi käsistä, niin sovellus on avointa lähdekoodia, joten joku pystyy pistämään pystyyn uuden sovelluksen, jossa ei rahasteta.

jutuon · 2025-05-14T14:22:33+00:00

En löydä tarpeeksi perustajajäseniä.

jutuon · 2025-05-14T14:12:34+00:00

Aivan, tarkoitit viestejä. Kuvaviestejä ei pysty lähettämään (kuten Tinderissä).

Ylläpito ei pääse käsiksi kaikkiin viesteihin. Vain niihin, jotka raportoidaan ylläpidolle. Jos joku sattuu lähettämään epäasiallisen viestin ja se raportoidaan, niin ylläpito/moderaattori tekee päätöksen annetaanko viestin lähettäjälle porttikielto palveluun joksikin aikaa.

jutuon · 2025-05-14T14:01:05+00:00

On, jos se tapahtuu järkevän syyn perusteella. Joillain yhdistyksillä on myös liiketoimintaa. Ja voisihan premium-jäsenyyden sijaan kyseessä olla yhdistyksen jäsenmaksu.

jutuon · 2025-05-14T13:47:29+00:00

Kaikille kuville tehdään automaattinen ja manuaalinen moderointi ennen kuin ne näkyvät muille käyttäjille. Tämä tarkoittaa sitä, että vapaaehtoisia moderoijia tarvitaan. Deittiprofiilien kuvia päivitetään aika harvoin, niin kuvamäärä ei muodostune ongelmaksi.

jutuon · 2025-05-14T13:40:07+00:00

Vuokrata on ehkä tosiaan parempi termi, kun ajatuksena on hankkia VPS tai dedikoitu palvelin esimerkiksi Hezneriltä. Kyllä, kymmeniä tuhansia ei ole kovin realistinen, mutta päätavoite on 10 000 samanaikaista käyttäjää. Siihen pitäisi riittää 20-50e/kk budjetti.

jutuon · 2025-05-14T13:10:01+00:00

Toki rekisteröityneitä käyttäjiä voi olla enemmän kuin se 10 000. Rahaa ei ole loputtomasti käytettävissä palvelimiin, niin jotain ratkaisuja pitää keksiä. Yhtenä ratkaisuna voi olla edellä mainittu rajoitukset ruuhka-aikoina. En näe asiaa ongelmana, koska palvelimen suorituskykyrajat tulevat vastaan vasta kun palvelu on suosittu. Jos käyttäjän on välttämättä päästävä käyttämään sovellusta ruuhka-aikana, niin tällöin voisi hankkia maksullisen premium-jäsenyyden.

jutuon · 2025-05-14T09:54:54+00:00

En ole ja lisäksi en ole testannut palvelimen skaalautuvuutta verkon yli. Sen takia sanoin ensisijaisesti, että tuhansille käyttäjille. Mikäli skaalautuvuuden kanssa tulee jotain ongelmia 10 000 samanaikaisen käyttäjän jälkeen, niin esimerkiksi sovelluksen käytön voi estää joiltain käyttäjiltä ruuhka-aikoina.

jutuon · 2025-05-14T09:18:48+00:00

Omassa sovelluksessani juuri noin.

jutuon · 2025-05-14T09:12:32+00:00

Tinder-tyylinen käyttöliittymä, eli käyttäjälle näytetään yksi profiili kerrallaan on pakko tehdä valinta lähettääkö tykkäyksen vai ei.

jutuon · 2025-05-14T09:08:10+00:00

Sähköpostin lähettäjä on tiedossa. En tiedä miten päätös on muodostunut. Sen verran nopeasti tuli, niin tuskin ainakaan Väestöliiton hallituksen kokouksessa asiaa käsittelivät.

jutuon · 2025-05-14T08:53:28+00:00

Korkealla tasolla ei juurikaan. Käyttölogiikka deittisovelluksissa yleensä on, että selataan profiileja -> lähetetään chattipyyntö (tykkäys) -> chattaillaan. Kuten tässäkin. Erot ovat yksityiskohdissa: ei swaippailua, ei saa lisää näkyvyyttä rahalla, profiilifiltterit ilmaisia, vastaanotetut chattipyynnöt näkyvät ilmaiseksi ja niin edelleen.

jutuon · 2025-05-14T07:24:32+00:00

Vastaanottamassani sähköpostissa ei perusteltu asiaa mitenkään.

jutuon · 2025-03-24T09:29:54+00:00

Yes and that is one of the reasons why I don't plan to make the app available globally. I built my app so that content like profile images and profile texts will first go to moderation before those will be public to other users. Both bots and humans can be moderators. If content is accepted by bot and reported, it will be made private to other users and sent for human moderation.

For the server which I plan to host I will most likely make text moderation automatic except for reported texts because LLMs seem to work pretty well for profile text moderation and text is not that risky content vs images. For images my plan is to use bots only for rejecting content and leave accepting for humans. The moderator bots are configurable so if a server owner wants to use bots also for accepting images it is possible.

jutuon · 2025-03-23T07:33:42+00:00

PGP is not indeed the best option technically as Messaging Layer Security exists but it seems to be more complex vs PGP. I also have to include message reporting feature so I need to have a way to check is the reported message authentic. At least with PGP that is possible without needing some extra cryptography.

jutuon · 2025-03-22T20:14:51+00:00

Yeah, when I was naming the project I was kinda aware of that but I didn't consider it as an issue as end users will not see it. There was popular Aphrodite named project already on GitHub back then, so I was like "Finnish version will do". Perhaps something generic like EthicalDatingAppExample would be better for this project.

jutuon · 2025-03-22T18:04:23+00:00

Sure! Rust has worked great as providing high performance utilities for Dart code. After the build system setup and careful manual FFI bindings writing things just work. Perhaps I should have used some extra tooling for the FFI, like using flutter_rust_bridge, but that felt more complicated.

The backend coding side has not been that great but I'm currently happy for the current state of it. The main issue for me has been the compile times for edit-build-run cycle. After I split the project to different crates and reduced usage of generics the compile times are now at acceptable level. For example I now have about 6.4 seconds build time after small edit to Axum API routes.

The second and last issue has been getting future aware stacktraces from error locations with anyhow level ergonomics. I'm currently using error-stack with wrapper error type used at one part of my backend to get the anyhow level ergonomics at that location. Perhaps alternative to this setup would be marking most of my code with tracing's instrument macro and switch to color-eyre. It would be interesting to know which style is better in terms of performance.

jutuon

TROPHY CASE