-
-
Notifications
You must be signed in to change notification settings - Fork 6.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support "twitter lists" #134
Comments
Thoughts on this subject: a) Where are lists stored, server-side or client-side? b) Once lists are implemented (either side), functionality can be added to
These don't need additional server support, but makers of different apps should agree on a common format for sharing lists. Easily sharing lists between users through toots will help mitigate the current discoverability problem. |
I'd like to point out one major benefit of lists: they allow users to "privately follow" people without publicly disclosing their interests (e.g politics, religion, sexuality...). |
…1.6.1 本家v1.6.1に追従
An idea I've been playing with, to solve the same issue, but differently, is to apply filtering on the client side. That is, the server would have the same timeline it has now, and the client would sort it into lists, based on arbitrary rules - which could even be some custom JS running in the browser for each incoming message. The filters would tag statuses, and the client would display them as lists, or in any other way it finds appropriate. The server could store the rules, as a blob, so that they would be available for every client that supports this. This way, the server doesn't have to maintain lists, or even care about how to add content there. The user would have much more freedom too, because they'd have more options than manually adding people one by one to any number of lists. I could have a "list" that has a few people, and all statuses that contain a phrase, or a tag, or are part of a context which is already part of this group. This way, if I have someone on a list, any replies to their toots will also get to the list (assuming the replies somehow appear on my timeline too). In other words, I'd push this into the clients, because that's more practical, more flexible, and easier to do too. The downside of this is that one will need to follow others to have their statuses appear on the lists - there is no private follow. Not sure if this is a good or a bad thing. As for sharing lists: one would share filtering rules, instead of lists. For ease of use, the most simple rules (filtering by username) could be made easier to share by explicitly exposing that in the UI. |
@algernon. You’ve just basically invented IMAP Sieve. Might as well reuse syntax and functionality. |
Yes, Sieve is where I got the inspiration from, except this'd run filters on the client side. My first thought was to allow arbitrary JavaScript functions (gets the status/notification as input, returns a list of tags), for maximum flexibility. But this would only work for clients that can support running JS. |
I would argue that both Sieve and JS are suboptimal from UX point of view. Not all users can write code for what Twitter and others can achieve with a simple UI. Moreover, it’s hard to share code. On top of that while Sieve is code at least it’s not Turing-complete, JS can do arbitrary things including leaking your private toots, stealing your credentials, posting as if it was you, mining crypto currency, or really anything. It’s a powerful solution, but I’m convinced it’s wrong on many levels. |
JS - and code - if exposed on the UI is wrong, indeed. It's wrong for the average user who just wants to manage lists, but it is a powerful tool for the advanced user who wants complicated rules. Having JS at the lowest level, and building a limited set of exposable features on top of it would benefit both those who just want lists (they'd have an UI that acts like that, where you can export / import lists), and those who want to do more complicated things. Yes, it can be abused, but that's a price I'd be willing to live with for the power it'd give me. (For the record, the client I'm working on, will have JS functions under the hood, with a list-like UI built on top of it. You'll be able to take control of the full power of JS if you host the client on your own, and use the list-like UI otherwise.) |
+1 for this functionality. Lists are great for aggregating similar accounts together, like game development or political news. Questions and suggestions for the feature:
|
My 2¢.
|
Update index.js
When this platform gets traction it will be really useful to be able to group users in different "lists". In general timelines are too verbose.
And to be able to continue where you left off later.
The text was updated successfully, but these errors were encountered: