Beiträge von HiDavid

    An HiDavids Stelle würde ich dem tatsächlich ein wenig Zeit widmen und so ziemlich alles sichern, was dir in den Kopf kommt. Denn dann ist es weg vom Markt und du kannst mit vielen Domains auf eine Seite linken. Macht durchaus Sinn.


    Das ist die Falle, in die jeder von uns schon mal getappt ist: Noch kein fertiges Produkt, aber sämtliche Domainnamen inkl. Tpyo-Domains ;-)

    Auf jeden Fall wird die Namensgebung wichtig - aus meiner Erfahrung heraus würde ich aber erst dafür sorgen wollen, einen MVP zu Wasser gebracht zu haben.

    Für den letzten Punkt werde ich mir Hilfe suchen müssen, denn da bin ich nicht in dem Maße bewandert, wie es notwendig werden wird. Entweder gegen direkten Münzeinwurf oder gegen eine Beteiligung.


    Aber dafür ist es erst einmal wichtig, ein MVP zu haben. Und wenn ich so auf meine Liste schaue, ist für die wirklich grundlegende Funktionalität nicht mal mehr so viel notwendig*.

    * Ich spreche da wirklich von einem MVP, also bitte nicht annehmen, ich würde damit sagen, dass morgen ein neues MSD das Licht der Welt erblickt ;-)

    Ein kleines Update: Ich warte derzeit noch auf einen Bugfix im Bereich Frontend, habe aber für das Backend zu verkünden:


    Neu dazu gekommen: Ein PhysicalAttribute Scorer.

    Neben dem, was SD oder SB sich an den Rahmenbedingungen des Arrangements vorstellen können (Entfernung, Exklusivität (beidseitig oder auch nur einseitig), ...) fallen nun auch Größe (min,max, nullable), Gewicht (min,max,nullable), Fitness-Level und mehr ins Gewicht.


    Dies werde ich in der nächsten Zeit noch um andere Profanitäten ergänzen.


    Derzeit ist es so gestaltet, dass ich z.B. konkret nach Frauen suchen kann, die unbedingt kleiner sind als ich. Oder mir ist das nicht so sehr wichtig, aber ein gesunder BMI ist mir wichtig.


    Die AI war so freundlich, aus den Test-Cases folgende lesbare Zusammenfassung zu erstellen:



    PhysicalAttributesScorer (0-40 points)

    Evaluates the compatibility of physical attributes between model and client based on their preferences.

    Scoring Logic:

    The scorer evaluates both directions (model's attributes vs client's preferences and vice versa):

    • 5 points per attribute: Height is within desired range
    • 5 points per attribute: Weight is within desired range
    • 5 points per attribute: BMI is within desired range
    • 5 points per attribute: Fitness level meets or exceeds expectations
    • 3 points: Fitness level is related/similar to expected range
    • 0 points: Attribute doesn't match or no data available when preference exists

    Maximum 20 points per person, thus maximum 40 points total


    Important: "No Preference" vs "No Data"

    The scorer distinguishes between three scenarios:

    1. No Preference Set (e.g., min_height = null AND max_height = null)
      • Attribute is not scored at all (neutral, doesn't affect total)
      • This is intentional: not everyone cares about every attribute
    2. Preference Set + Data Available + Match
      • If match: +5 points for exact attributes (height, weight, BMI)
      • If within range or higher: +5 points for fitness level
      • If related fitness level: +3 points
    3. Preference Set + No Data Available OR No Match
      • 0 points (either we can't verify it, or it doesn't match)

    Example: If a search profile sets min_height = 170 but not min_weight, then:

    • Height will be scored (5 points if match, 0 if not)
    • Weight will be ignored (0 points, but not a negative - just not considered)


    Fitness Level Scoring (Nuanced)

    Similar to education levels, fitness levels are scored with nuance:

    • 5 points: Fitness level is within desired range (min to max)
    • 5 points: Fitness level is higher than maximum (better than expected)
    • 3 points: Fitness level is related/similar to expected range
    • 0 points: Fitness level is below minimum, doesn't match, or no preference/data

    Fitness Level Hierarchy:

    1. SEDENTARY (lowest)
    2. LOW
    3. MEDIUM
    4. HIGH
    5. VERY_HIGH
    6. ATHLETIC (highest)

    Related Levels (receive 3 points):

    • SEDENTARY ↔ LOW
    • LOW ↔ SEDENTARY, MEDIUM
    • MEDIUM ↔ LOW, HIGH
    • HIGH ↔ MEDIUM, VERY_HIGH
    • VERY_HIGH ↔ HIGH, ATHLETIC
    • ATHLETIC ↔ VERY_HIGH


    Physical Attributes in Search Profiles

    Search profiles support the following physical attribute ranges:

    • Height: min_height to max_height (in cm)
    • Weight: min_weight to max_weight (in kg)
    • BMI: min_bmi to max_bmi (calculated automatically from height/weight)
    • Fitness Level: min_fitness_level to max_fitness_level

    All attributes are nullable - if not specified in the search profile, no scoring is applied for that attribute.

    Examples:

    Example 1: Perfect Physical Match (Both Directions)

    • Client wants: Height 165-175cm, Weight 55-65kg, Fitness: MEDIUM-HIGH
    • Model has: Height 170cm, Weight 60kg, Fitness: HIGH
    • Model's evaluation: Height ✓ (5) + Weight ✓ (5) + Fitness ✓ (5) = 15 points
    • Model wants: Height 175-185cm, Weight 70-80kg, Fitness: HIGH-ATHLETIC
    • Client has: Height 180cm, Weight 75kg, Fitness: ATHLETIC
    • Client's evaluation: Height ✓ (5) + Weight ✓ (5) + Fitness ✓ (5) = 15 points
    • Total: 30 points (both match all specified attributes)

    Example 2: Partial Match with Missing Data

    • Client wants: Height 160-180cm, Weight 50-70kg, Fitness: HIGH-ATHLETIC
    • Model has: Height 175cm (matches), Weight: not set, Fitness: MEDIUM (related to HIGH)
    • Result: 5 (height) + 0 (no weight data) + 3 (fitness related) = 8 points for model

    Example 3: No Preference = Not Scored

    • Client has NO physical preferences set (all null)
    • Model has: Height 170cm, Weight 60kg, Fitness: HIGH
    • Result: 0 points (not because it's bad, but because client doesn't care about these attributes)

    Example 4: Exceeds Expectations

    • Model wants: Fitness: MEDIUM-HIGH
    • Client has: Fitness: ATHLETIC (higher than max)
    • Result: 5 points (better than expected is still good)

    Example 5: Preference Set but No Data

    • Client wants: Height 170-185cm
    • Model has: Height not set (null)
    • Result: 0 points (client cares about height, but we can't verify it)

    Example 6: Outside Range

    • Client wants: Height 170-185cm
    • Model has: Height 160cm (below minimum)
    • Result: 0 points (doesn't meet the requirement)

    Example 7: Mixed Attributes

    • Client wants: Height 165-175cm, Fitness: HIGH-ATHLETIC (no weight/BMI preference)
    • Model has: Height 170cm (matches), Weight 60kg (no preference set), Fitness: MEDIUM (related to HIGH)
    • Result: 5 (height) + 0 (weight not requested) + 3 (fitness related) = 8 points


    BMI Calculation

    BMI is automatically calculated from height and weight:

    • Formula: BMI = weight (kg) / (height (m))²
    • If height or weight is missing, BMI is null
    • BMI preferences in search profiles are optional and independent of height/weight preferences
    • You can set BMI preferences without setting height/weight preferences (and vice versa)

    Important: The BMI preference is evaluated independently. If you set both height/weight ranges AND BMI range, all three must match to get full points for each.

    Ne, eine Bewertung sexueller Dienstleistungen hatte ich auch nicht im Sinn. Das wäre dann ja wirklich ein Klon von Paysex-Seiten und eigentlich sollte Sugardating ja eben mehr sein als nur eine Nummer gegen Zahlung.

    Schwierig mbMn.

    • Ich persönlich täte mich schwer, Dritte als potentielle Mitleser in einer privaten Kommunikation zu haben. Sicher soll man nicht von sich auf andere schließen, aber nicht jeder/jedem wird das schmecken, denke ich.
    • Das könnte dazu führen, dass die schwarzen Schaf*innen auf andere Kommunikationskanäle wechseln. Ist ja schon jetzt landläufige Praxis, wie man hier so liest.

    Da bin ich dabei. Ich bin der Meinung, dass Schwellwerte hier der bessere Weg sind und die Kommunikation nicht - insbesondere nicht bei solchen "Kleinigkeiten" - mitgelesen werden sollte.

    Tatsächlich stimme ich da zu: Es ist die Frage, ob integrieren oder bewusst ausschließen am Ende das Problem mit Personen löst, die nur vorgeben an einer SD/SB-Beziehung interessiert zu sein, tatsächlich jedoch Bildchen verkaufen wollen.


    Strategisch wäre es vielleicht auch klüger, sich vom klassischen Paysex zu entfernen, da wir alle nicht wissen, was passiert, wenn die Union mit dem Wunsch nach dem nordischen Modell einmal freie Hand bekommt.

    Nein, in meinem Beispiel wäre es ja so: Eine schlechte Bewertung an sich löst nichts aus, wird weder angezeigt noch in irgendeiner Form berücksichtigt.

    Ab X Bewertungen der selben Art (mit nachvollziehbarem Kontakt, d.h. wenn tatsächlich eine Konversation gestartet wurde), wird es berücksichtigt.


    Ich denke da auf jeden Fall einmal drüber nach. Es kann schon helfen, das einzuhegen und offen zu machen, da stimme ich Dir zu.

    Das könnte aber Tür und Tor für Erpressung öffnen "triff dich mit mir oder ich bewerte dein Profil schlecht!".

    Dann müsste eine Überprüfung der negativen Bewertungen durch jemand Dritten stattfinden anhand von Chatverläufen oder Ähnlichem.


    Ebenso sollten dann auch die Männer bewertet werden können, wenn sie nur Sextreffen suchen oder nicht zuverlässig sind etc.pp.....

    Hi und danke für Deine Antwort,


    absolut. Dessen bin ich mir bewusst und ganz so leicht soll es halt auch nicht werden.


    Möglich sind Schwellwerte: Wenn x Mitglieder das Feedback geben, dass die Dame nur Bilder verticken will, dann wird das Mitglied entsprechend geflagged (oder was auch immer).


    Ich glaube überall dort, wo es Zurückweisungen geben kann, insbesondere in dieser "Branche", muss man aufpassen, dass es keine Rachebewertungen oder entsprechende Erpressungsversuchte gibt. So etwas gibt es ja schon bei der Eisdiele um die Ecke - und da ist keine so starke persönliche Note vorhanden.

    Ich würd denken es ist zu 99% das problem das man nicht verifizieren kann was der andere WIRKLICH will. Wenn es klar ist das es kein "wirkliches SB" ist wär mir egal wieviele nur Bilder verkaufen wolln.

    Die Idee war ja auch tatsächlich, die Suche, das "Matching" verbindlicher zu machen. Mein Plan war, dass man ein Profil dann entsprechend bewerten kann, wenn die Angaben nachvollziehbar falsch waren und eigentlich statt einer SB/SD-Beziehung dann doch nur Fotos verkauft werden wollten.

    Um ehrlich zu sein, finde ich, dass es bereits ziemlich überzeugend aussieht.


    Aber wie ich bereits gesagt habe, befürchte ich, dass deine Anstrengungen umsonst sein werden, wenn du es nicht schaffst, eine kritische Masse an Nutzern (insbesondere Frauen/SBs) zu erreichen. Das wird die eigentliche Herausforderung sein.

    Ich stimme da absolut zu.


    Das ist der Grund, warum ich den Prozess möglichst schlank halten möchte und bisher ist das auch ganz gut gelungen.


    Ich gehe allerdings auch sehr davon aus, dass meine technische Seite da auch noch ergänzt werden muss. Ich bin sicher Geschäftsmann, IT'ler und vielleicht auch im technischen Detail nerdy. Aber ich werde da Unterstützung benötigen.


    Wir werden mal sehen, wohin das so gehen mag ;-)

    So ein wenig ist es heute voran gegangen:


    Was jetzt gerade geschieht: Ich habe das Scoring für die Beziehungen ein wenig differenziert. Die AI hat das, was in Code gegossen ist, mal zusammen geschrieben:



    Scoring Logic

    When arrangement preferences match:


    Both Want an Exclusive Arrangement:

    Model StatusClient StatusScoreDescription
    Single/Divorced/WidowedSingle/Divorced/Widowed10Perfect: Both available
    Single/Divorced/WidowedMarried/In Relationship7Good: Typical sugar dating scenario
    Single/Divorced/WidowedOpen Relationship7Good: Client can offer exclusivity
    Open RelationshipSingle/Divorced/Widowed7Good: Model in open relationship
    Married/In RelationshipMarried/In Relationship2Questionable: Both committed
    Open RelationshipOpen Relationship7Good: Both in open relationships


    Both Want a Non-Exclusive Arrangement:

    Model StatusClient StatusScoreDescription
    Open RelationshipOpen Relationship10Perfect: Both in open relationships
    AnyAny7Good: Status matters less for non-exclusive

    When arrangement preferences differ:

    • 2 points: Fundamentally incompatible (one wants exclusive, other doesn't)

    When no relationship status provided:

    • 5 points: Benefit of the doubt (acceptable match)


    Das ist auch noch nicht fix - da wir die eigentlichen Suchaufträge speichern und die Scorings jederzeit neu durchrechnen können, sind Anpassungen hier einfach schon im Vorfeld bedacht.

    Sowohl Matching als auch Scoring sind nunmehr modular aufgebaut und können jederzeit um weitere Filterebenen erweitert werden.


    Als nächstes gibt es eine erste Anbindung einer UI. Die ist vermutlich noch nicht perfekt, erhebt auch noch nicht den Anspruch, soll aber schon einmal die API konsumieren und auch einfach mal die technischen Hintergründe "spürbar" machen.

    Der erste Aufschlag sieht so aus:


    Bitte seid da gnädig. Das ist alles noch nicht in der Form, in der das am Ende sein soll (s. Shutterstock Placeholder), es geht da gerade nur darum, die technische Schicht nun nutzbar zu machen.

    Früher war es ja deutlich einfacher und schneller möglich, bei diversen Freemail-Diensten einen Account anzulegen. Davon profitiere ich heute immer noch. ;)

    protonmail erlaubt nette Aliase und einige Provider unterstützen die +-Notation. Das hilft auch 🙂

    Das ist selbstverständlich legitim, aber zumindest eine kleine Statusinfo hätte man durchaus hier deutlich früher posten können. Kein Mensch ist irgendwo so sehr eingebunden, dass er das nicht innerhalb eines Dreivierteljahres schafft.


    Da gebe ich dir recht, das hätte ich tun sollen.

    Ich glaube, dass die Gründe, die ich hatte - neben der Projektarbeit - gut nachvollziehbar sind, auch wenn ich sie nicht öffentlich diskutieren möchte, aber ein kurzes Update hätte ich schreiben müssen.


    Ich bedaure, dass ich das nicht getan habe. Mea culpa.