Skip to content

Instantly share code, notes, and snippets.

@ummjackson
Created November 8, 2016 05:21
Show Gist options
  • Star 7 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save ummjackson/786363fa13bf98785f0dca5c0fd0ca3c to your computer and use it in GitHub Desktop.
Save ummjackson/786363fa13bf98785f0dca5c0fd0ca3c to your computer and use it in GitHub Desktop.
Brainstorming about what Twitter could be... 🤔

This is a WIP

Basics

  • Implement core feature set of Twitter (users, statuses, followers/friends, lists, blocking)
  • Do not implement direct messaging initially (there are already any IM clients out there)
  • Implement 1:1 replica of Twitter v1.1 API
    • Very generous limits up-front (only what's needed to avoid denial of service / spam attacks)
    • Clients must register a Client ID prior to making requests (same as Twitter)

User Registration/Authorization

  • Forced phone + email verification for new account creation (to weed out spam bots)
  • Users can request "verified" status
    • We should have a manual internal system initially, which should be quick to review then "Approve" or "Deny"
    • To become verified, a user must:
      • Have a valid cell number, verified via a SMS code upon initial sign up (Note: Once an account is verified, that cell number can only be used with that one account, and no other new/existing accounts - user will need to change the cell number on other associated accounts prior to applying for verification)
      • Have a non-default avatar image set
      • Connect via oAuth with at least two other active social media presences (eg. Facebook, Twitter, LinkedIn, Soundcloud) that were created > 6 months ago
      • Pay an annual fee of $4.99 (cost of a Starbucks latte), facilitated via Stripe or PayPal internally
  • 2FA enforced by default for all users (using phone + email collected at sign up)
  • Utilize oAuth 2.0 Bearer token auth for clients
    • Ability to revoke clients at the Client ID and individual token level
    • Ability to suspend all sessions across all Client IDs

Status/reply thread features

  • Every post is organized into a status -> replies hierachy
    • A "status" is a root-level post, not created in relation to any other post
    • A "reply" is a sub-level post anchored to either a) a root-level status or b) another reply preceding this reply
  • Additional, optional metadata set with each status + reply:
    • Attached media (ie. images, videos, links - 1 "primary" attachment per status/reply, remainder are rendered as hyperlinks)
    • Location
    • Device
    • NSFW flag
  • When creating a new status on your own profile (which could turn into a thread with replies), you will have a "Visibility:" setting with the following options
    • Everyone (default)
    • People you follow
    • Private (just yourself)
  • When creating a new status on your own profile (which could turn into a thread with replies), you have a "Allow replies from:" setting with the following options:
    • Everyone (default)
    • People you follow
    • Only me (this option is good for long-form threads without interuption)
  • When entering an existing thread started by another user, you inherit their "Allow replies from:" setting from the initial status they posted
  • "Mute notifications" option: You can opt-out of receiving future notifications for updates to any status or reply. Selecting this option will opt you out of all noticiations in relation to both the status and the subsequent replies
  • "Leave thread" option: If you've taken part in a thread, clicking this option will a) opt you out of all futher notifications as above and b) block users from continuing to hyperlink mention you in subsequent replies. Users can still write @username as static, non-clickable text manually.
  • "Remove mention" option: Available on any status/reply in which you're mentioned, will convert the hyperlinked @username to static, non-clickable "@username" text, and will also stop you receiving any furhter notifications on that thread.

Anti-harassment features

  • "Soft Block" option: Same as Twitter's option, blocks the user from viewing your account or posts while logged in.

  • "Deep Block" option: Choosing to deep block a user automatically blocks all other accounts (past and future) created from the same IP address, associated email address or phone number of the account you're blocking. Additionally, content from your account will not be served to the IP address associated with offending account - regardless of logged in status.

  • Block list subscriptions: Just like regular "lists" or "collections" of users, a user can subscribe to another user's block list if they've made it public (under Settings)

  • Word filters: Allows you to specify a list of words or phrases (one per line) that will not be shown in your home stream. All statuses + replies + notifications containing theses words or phrases will be filtered from your view.

  • User type filters: Allows you to specify criteria for filtering out statuses + replies + notifications from users with certain traits:

    • Mutual followers
    • Age of account
    • Default avatar
    • No. of followers
    • No. of tweets
    • Follows X user
  • Report abuse: Robust abuse reporting system, allow for multiple image uploads and unlimited text input for details of harassment. 24-48 hour SLA (TBD: develop anti-harassment policy, this is key key key!!)

Settings

  • Enable inline rich media (default: true for all):

    • Images
    • Video
    • Link Previews
  • Stop users you've blocked from @ mentioning you (default: true)

    • This will block the ability for a blocked user to include the text or hyperlink "@username" in any of their tweets
  • Allow others to subscribe to your block list (default: false)

    • This will make your block list public, allowing others to subscribe and also block accounts you have blocked
@ummjackson
Copy link
Author

👍 to both ideas @fabiofederici!

i hadn't even thought of hashtags, that's something we'll need to flesh out.

@andrewvy
Copy link

andrewvy commented Nov 8, 2016

What do you think of an archiving feature? Marking a post so that it archives over a certain amount of time, locking it from future public interaction? e.g: preventing people from bumping / replying to old posts.

Or even auto-expiring posts a la Snapchat?

These could be a post-level setting + user-default setting as well.

@Zorlin
Copy link

Zorlin commented Nov 8, 2016

Small edit:

receiving any furhter notifications on that thread.

should be

receiving any further notifications on that thread.

@fabiofederici
Copy link

  • delete/edit (by Jackson)

@Zorlin
Copy link

Zorlin commented Nov 8, 2016

Other suggestion:

  • Allow others to subscribe to your block list (default: false)

Maybe make that more granular - enable people you're following to subscribe to and see your block list, instead of making it public.

@kylemcdonald
Copy link

IP address bans don't work. When a mobile device cycles network connection it gets a new IP. All the clients in a single university dorm or business often appear as a single IP. Otherwise this is looking great. I think some kind of migration feature might be important if you want to him critical mass. Also, I think the ownership and vision for the project should be made clear from the start: mainly people don't want to invest time in something that will be shut down, changed too significantly without community approval, or sold to someone with a different set of goals. Finally, the anti-harassment features all remind me a lot of Caroline's work http://www.washingtonpost.com/amphtml/news/the-intersect/wp/2015/05/14/the-conclusive-expert-guide-to-saving-twitter-from-its-trolls/ and I'm sure she'd be happy to join or talk more about this!

@marshallhayner
Copy link

Block by flash cookie, add a suggested block feature... If you mark a user as suggested block they will show up to any of your followers as suggested block, also you'll see a visible warning before adding them that they've been added to suggested block by someone you follow.

@fabiofederici
Copy link

Something that came to mind while reading marshall's comment: it'll be critical to keep some of the feature subtle. While they should be simple to understand and easy to access, we need to be careful for them not to be too intrusive to the overall UX, we still want people to connect & communicate 😃 but we could be smart about that, let's say if more than X people I follow have blocked this person I get an alert.

@andrewvy
Copy link

andrewvy commented Nov 8, 2016

All OAuth applications should have fine-grain + detailed permission options + last recently used endpoints.

I really like Github's approach here, where applications have accounts themselves.

image

@kylemcdonald
Copy link

some more leftover thoughts... there are three situations wrt IP addresses:

  1. multiple users, one IP (business, dorm, etc)
  2. multiple IPs, one user (mobile network change, IP reset by ISP, browsing with tor)
  3. one user, one IP (static IP from ISP)

arguably, you can detect each of these situations. but implementing an IP ban would be counterproductive or inconsistent for cases 1 and 2. so here's another idea: have an option that says "my account is only visible to logged-in users" (or some variation on a minimum requirement of activity for viewing a user's posts). this would mean that if someone is blocked by that user, they would have to create (and possibly build up) another account to view their posts again.

this would be accomplished with a combination of features: like having a private account, but with automated restrictions for who could follow like caroline's minimum follower requirements ("do not allow accounts with less than <100> followers to follow me", etc.) rather than manually approving each follower.

@developit
Copy link

Just adding to the discussion here: first-class and welcoming support for third party / alternative frontends is a must!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment