[GH-ISSUE #39] Maigret Transform tweaks (suggestion) #999

Closed
opened 2026-05-03 01:49:35 -05:00 by GiteaMirror · 5 comments
Owner

Originally created by @FarallonWest on GitHub (Nov 11, 2025).
Original GitHub issue: https://github.com/reconurge/flowsint/issues/39

First off THANK YOU!

  1. Currently the Maigret transform is only available in social profile and output is social profile. This is usually used when you have a username and don't have the social profile or need to exhaust the social profiles.

Suggest changing and either making it and Sherlock available through both username and social profile or only username.

  1. The output has the type, property and username as the title on the node. This makes it difficult to run other transforms, yet you need to know this visually.

Suggest being able to identify a limited data field within the node to run other transforms on the entity node. For example, if I want to scrape the profile that was found, being able to select a url from the card of the entity would be helpful.

I know #2 is more complicated, but thought I would just toss it up.

Originally created by @FarallonWest on GitHub (Nov 11, 2025). Original GitHub issue: https://github.com/reconurge/flowsint/issues/39 First off THANK YOU! 1. Currently the Maigret transform is only available in social profile and output is social profile. This is usually used when you have a username and don't have the social profile or need to exhaust the social profiles. Suggest changing and either making it and Sherlock available through both username and social profile or only username. 2. The output has the type, property and username as the title on the node. This makes it difficult to run other transforms, yet you need to know this visually. Suggest being able to identify a limited data field within the node to run other transforms on the entity node. For example, if I want to scrape the profile that was found, being able to select a url from the card of the entity would be helpful. I know #2 is more complicated, but thought I would just toss it up.
Author
Owner

@dextmorgn commented on GitHub (Nov 11, 2025):

Hey @FarallonWest,

Thanks for this suggestion ! You're right, Maigret transform should probably start with Username as input, returning a SocialProfile as output.

That said, both of your points raise two aspects I'd like to work on :

In the first place, I think I might have overcomplicated the Username and SocialProfile, and am starting to think that maybe these two are redundant and could potentially be merged. I'd be happy to hear from you if you think of a particular data format /structure that could allow for merging the two.

Now for the more advanced part you mentioned: one enhancement I'd love to work on and make available in the future is indeed the ability to select the field to run the transform on, both using the transforms directly or in the flow builder.

Let me know what you think !

<!-- gh-comment-id:3519189760 --> @dextmorgn commented on GitHub (Nov 11, 2025): Hey @FarallonWest, Thanks for this suggestion ! You're right, Maigret transform should probably start with `Username` as input, returning a `SocialProfile` as output. That said, both of your points raise two aspects I'd like to work on : In the first place, I think I might have overcomplicated the `Username` and `SocialProfile`, and am starting to think that maybe these two are redundant and could potentially be merged. I'd be happy to hear from you if you think of a particular data format /structure that could allow for merging the two. Now for the more advanced part you mentioned: one enhancement I'd love to work on and make available in the future is indeed the ability to select the field to run the transform on, both using the transforms directly or in the flow builder. Let me know what you think !
Author
Owner

@FarallonWest commented on GitHub (Nov 12, 2025):

I am glad this was helpful! You are building something truly special.

I wondered about the redundancy with username and social profile as well. The difference being that sometimes when we start an investigation, we extrapolate a user name where we do not know for sure there is a social profile -- such as using the first part before @ in an email address. Where as, in this case, social profile is identifying a defined digital property that does exist -- such as an account on Threads. These are two different things, but they are interchangeable. For example, when I find a social media profile, I can use that username to find other usernames.

The transforms you chose (so far) of Maigret and Sherlock both use usernames. The social profile entity requires a url to start a transform and we don't always have that yet when we use those tools.

One way to consolidate those two things, but still show some sort of difference in a username that has a physical presence vs one that is an unconnected username, would be to assign a badge (different from the colored tag) and change the color based on type. A badge can be just a dot next to the name on the graph. Forum badges are a certain color, mainstream social media another color, etc. but indicate that an actual account might exist. (I say might because all these tools have false positives). I know this is far more complicated and I am not sure how clear it would be on the graph in practice vs keeping them as two different entity types.

I think your thinking of these as two different kinds of entities was spot on.

<!-- gh-comment-id:3519274215 --> @FarallonWest commented on GitHub (Nov 12, 2025): I am glad this was helpful! You are building something truly special. I wondered about the redundancy with username and social profile as well. The difference being that sometimes when we start an investigation, we extrapolate a user name where we do not know for sure there is a social profile -- such as using the first part before @ in an email address. Where as, in this case, social profile is identifying a defined digital property that does exist -- such as an account on Threads. These are two different things, but they are interchangeable. For example, when I find a social media profile, I can use that username to find other usernames. The transforms you chose (so far) of Maigret and Sherlock both use usernames. The social profile entity requires a url to start a transform and we don't always have that yet when we use those tools. One way to consolidate those two things, but still show some sort of difference in a username that has a physical presence vs one that is an unconnected username, would be to assign a badge (different from the colored tag) and change the color based on type. A badge can be just a dot next to the name on the graph. Forum badges are a certain color, mainstream social media another color, etc. but indicate that an actual account might exist. (I say might because all these tools have false positives). I know this is far more complicated and I am not sure how clear it would be on the graph in practice vs keeping them as two different entity types. I think your thinking of these as two different kinds of entities was spot on.
Author
Owner

@FarallonWest commented on GitHub (Nov 12, 2025):

I just went through and added another username to give you better feedback. The fields for the username are the same/similar to the social profile. There are some that can be removed to make it clear this is a username without one home vs a social profile that has an identified home. For example, the url of where a username exists is redundant in this case. Also where it exists is redundant.

<!-- gh-comment-id:3523432416 --> @FarallonWest commented on GitHub (Nov 12, 2025): I just went through and added another username to give you better feedback. The fields for the username are the same/similar to the social profile. There are some that can be removed to make it clear this is a username without one home vs a social profile that has an identified home. For example, the url of where a username exists is redundant in this case. Also where it exists is redundant.
Author
Owner

@dextmorgn commented on GitHub (Nov 12, 2025):

What would you say of this. A username is now basically a simple string (with optional platform and last_seen), and a SocialAccount depends on a Username.

# username
class Username(BaseModel):
    """Represents a username or handle on a specific platform."""
    value: str = Field(..., description="Username or handle string")
    platform: Optional[str] = Field(None, description="Platform name, e.g., 'twitter'")
    last_seen: Optional[str] = Field(None, description="Last time this username was observed")
class SocialAccount(BaseModel):
    """Represents a social media account (the 'home' of a username)."""
    username: Username
    display_name: Optional[str] = None
    profile_url: Optional[str] = None
    avatar_url: Optional[str] = None
    bio: Optional[str] = None
    location: Optional[str] = None
    website: Optional[str] = None
    created_at: Optional[str] = None
    followers_count: Optional[int] = None
    following_count: Optional[int] = None
    posts_count: Optional[int] = None
    verified: Optional[bool] = None
    is_private: Optional[bool] = None
    is_suspended: Optional[bool] = None
    associated_emails: Optional[List[str]] = None
    associated_phones: Optional[List[str]] = None
<!-- gh-comment-id:3523953944 --> @dextmorgn commented on GitHub (Nov 12, 2025): What would you say of this. A username is now basically a simple string (with optional platform and last_seen), and a `SocialAccount` depends on a `Username`. ```python # username class Username(BaseModel): """Represents a username or handle on a specific platform.""" value: str = Field(..., description="Username or handle string") platform: Optional[str] = Field(None, description="Platform name, e.g., 'twitter'") last_seen: Optional[str] = Field(None, description="Last time this username was observed") ``` ```python class SocialAccount(BaseModel): """Represents a social media account (the 'home' of a username).""" username: Username display_name: Optional[str] = None profile_url: Optional[str] = None avatar_url: Optional[str] = None bio: Optional[str] = None location: Optional[str] = None website: Optional[str] = None created_at: Optional[str] = None followers_count: Optional[int] = None following_count: Optional[int] = None posts_count: Optional[int] = None verified: Optional[bool] = None is_private: Optional[bool] = None is_suspended: Optional[bool] = None associated_emails: Optional[List[str]] = None associated_phones: Optional[List[str]] = None ```
Author
Owner

@FarallonWest commented on GitHub (Nov 13, 2025):

That works!

I'd suggest changing username:

"Represents a username or handle on a specific platform"

To

"Represents a username or handle on any platform"

<!-- gh-comment-id:3526594998 --> @FarallonWest commented on GitHub (Nov 13, 2025): That works! I'd suggest changing username: "Represents a username or handle on a specific platform" To "Represents a username or handle on any platform"
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/flowsint#999