buckket / twtxt

Decentralised, minimalist microblogging service for hackers.
http://twtxt.readthedocs.org/en/stable/
MIT License
1.92k stars 79 forks source link

sync following list #36

Open kitchen opened 8 years ago

kitchen commented 8 years ago

This is something I'd like to see but don't want to implement right this moment (I should be getting ready for the superbowl party I'm going to, not writing python, dammit!), but I thought I'd share to see if others had ideas for how this might work.

I use 2 computers pretty regularly, so being able to synchronize the list of folks I follow is going to be a critical feature for adoption for me :)

I had something in mind similar to pre_tweet_hook from #32 to have it pull that down when you look at timeline or follow someone, and a post hook to publish it. Currently the list of who I follow is not public, and I'm not sure if that should be (I personally don't care, but others might), or I would say just add a url to the config where my following list is published. Implementing it as a pair of hooks makes it so it can be as public or private as I want it to be.

Thoughts?

tedder commented 8 years ago

I like the idea of a second (public) file that contains metadata like your pic and followers. If you wanted the followers private it'd be a third file, I guess.

DracoBlue commented 8 years ago

You could use #22 to provide the in the file, too.

erlehmann commented 8 years ago

There is a standard for syncing following lists already. It is called OPML and supported by Mozilla Thunderbird and a lot of feed readers. Why not use that?

timofurrer commented 8 years ago

Well, OPML is not specifically for syncing following lists - It could be used thought. However, for the sake of UNIX tool integration, simplicity, and of course the hackiness-factor etc. I'm really against XML based communication..

erlehmann commented 8 years ago

@timofurrer OPML is supported for syncing following lists by Amarok, Bamboo, Feedly, Internet Explorer, Mozilla Thunderbird, Newsbeuter, Podget, Tiny TIny RSS and lots of other programs.

buckket commented 8 years ago

As mentioned earlier I want to keep things simple, for users and programmers alike. Making use of XML-based formats is a total overkill. I won’t go anywhere near that stuff with twtxt.

timofurrer commented 8 years ago

@erlehmann I totally get what you are trying to say .. but just because it's widely spread and used by many applications doesn't mean it's good (I don't say it's not good ..) and we should use it too. As far as I know the goal of twtxt is not to be compatible with all the tools you've mentioned. As the description says: ... service for hackers

erlehmann commented 8 years ago

@timofurrer what are your criteria for “good” if they are not among “it works”, “it is interoperable” or “it is widely implemented” ?

erlehmann commented 8 years ago

@buckket if you do not care about compatibility, you could just do it like newsbeuter, which consumes OPML and a $HOME/.newsbeuter/urls file where each line is a URL to a feed.

Benaiah commented 8 years ago

It would likely be simple to write an OPML<->twtxt converter if someone needed that, so I agree that it would be better kept out of the core twtxt app.

buckket commented 8 years ago

Like the idea to share ones following list. Best we combine it with #22 and #48.

adiabatic commented 8 years ago

I'd throw my twtxt config in ~/Dropbox/Apps/twtxt/config.ini or ~/Sync/Apps/twtxt/config.ini and, in bash:

alias twtxt="twtxt --config=…`

Not sure what to do about the cache files, though. On Linux, AFAIK, these things should go in $XDG_CACHE_HOME (~/.cache/twtxt/); OS X, ~/Library/Caches/twtxt/. On Windows, %LOCALAPPDATA%\twtxt seems to be the best place to put a cache.

Pinging @quite because he knows $XDG_* more than I do…and because I'd like this sort of thing in twet if I never get around to implementing it.

buckket commented 8 years ago

@adiabatic Yes, the cache file should go in another directory per default, but for the purpose of simplicity I just had thrown it together with the config file, as click only provides a function for resolving the config dir. Will fix this sometime soon, best by making the location of the cache file configurable.

As for the issue: Having an (optional) separate file with a complete list of ones followings, mimicking the config files’s syntax, seems like a sweet solution. We than can reference this file by a inline comment / metadata filed in the twtxt main file.