Live data from Hacker News

Telegram Ad Platform

promote.telegram.org

251–256 of 256 posts

Re: Telegram Ad Platform

#251
post #150

Earlier quoted context omitted.

Yes telegram is so much better than WA from a customer's point of view. The best thing I like about it is that it's an instant setup on every phone and doesn't require the Google backup integration which can take an hour to restore. Also the fact I can run it on multiple devices simultaneously is also kind of a big deal. Their API is also pretty amazing tbh. I wish all my friends were on tg instead of wa and i would…

Not all about Telegram is golden however. At some point last year, amidst the skyrocketing popularity of the app and WhatsApp coming under heat for various reasons, someone at Telegram thought of a fantastic (read: user-hostile) way to "increase engagement" - Show a persistent panel on the home screen with the name of every contact on your phone who uses Telegram, in the hopes that you would click one of them and eng…

Sorry, what's the problem there? I don't use Telegram, but it seems it's just putting that where otherwise would just be empty space?

Re: Telegram Ad Platform

#252
post #250

Earlier quoted context omitted.

> They are jurisdiction hopping to evade that responsibility. From a technical perspective, whoever is running those servers can access the data. That aspect is far more important than the legal hurdles. > Given the above: Do you trust any state's government? Yes, my own. But I understand that not everybody has that privilege.

Er, sorry, I meant "every", because you don't trust yours with Telegram – you trust a more or less random one, depending on their jurisdiction hopping location of the day.

I see. Well, you are correct. I'm sure that a particularly motivated entity with access to my Telegram could find something on me, and coercing foreigners with blackmail could be a good strategy for any government.

Re: Telegram Ad Platform

#253

Earlier quoted context omitted.

Speaking as Matrix project lead: we'd love to submit an RFC (or W3C proposal) once Matrix has sufficiently stabilised. Right now it's moving very fast though (e.g. we're about to totally change the sync API so that it's O(1) rather than O(N) with number of conversations). In terms of contributions to the Matrix spec; from a quick eyeball at https://spec.matrix.org/unstable/proposals/ , there are 95 different authors,…

We all know that 'independent matrix foundation' will never oppose the will of the leading vendor. Don't tell me about how you agree to everything in your wonderful community, tell me how you resolve conflicts? You and your company has all the leverage and no sane independent developer will invest in your protocol because he'll always have to play the catch up game.

An example of resolving conflicts is something like MSC2962 (https://github.com/matrix-org/matrix-doc/pull/2962) and MSC3216 (https://github.com/matrix-org/matrix-doc/pull/3216). Two proposals to solve the same problem, different ways. The first one was written by me; the second one was written by joepie91, who's a completely independent community member. Doesn't get much more of a direct conflict than this.

So, to resolve it, the spec core team (which is a mix of element employees and community members) went through the two proposals to compare them and concluded that joepie91's approach is better. So we're about to kill off MSC2962 and merge MSC3216 into the spec instead.

Please stop with all the disinformation - it'd be way more constructive to invest your energy into improving XMPP than trying to make Matrix out to be evil.

Re: Telegram Ad Platform

#254

Earlier quoted context omitted.

We all know that 'independent matrix foundation' will never oppose the will of the leading vendor. Don't tell me about how you agree to everything in your wonderful community, tell me how you resolve conflicts? You and your company has all the leverage and no sane independent developer will invest in your protocol because he'll always have to play the catch up game.

An example of resolving conflicts is something like MSC2962 ( https://github.com/matrix-org/matrix-doc/pull/2962 ) and MSC3216 ( https://github.com/matrix-org/matrix-doc/pull/3216 ). Two proposals to solve the same problem, different ways. The first one was written by me; the second one was written by joepie91, who's a completely independent community member. Doesn't get much more of a direct conflict than this. So,…

What you cite is not a conflict. It is a mild disagreement about the development of new features. A real conflict is when you have different entities with different implementations, and diverging views on how to develop the protocol, and the stake for the losing party is to abandon their investment in their existing implementation and starting over from scratch.

However, I already have the answer on how you plan to deal with such conflicts, you've said it yourself [1]. I'll quote:

> The idea on Matrix is that you say "Hi, I talk Matrix CS API 0.4" and be done with it - and you end up with much more social pressure to keep up to date with the current latest spec, because otherwise you are simply falling behind

If we say it in a less courteous manner, "Once we introduce changes, your independent implementation will be cut off from our network, and if you'll need several more months to implement changes, well, tough luck".

You see, I'm not saying Matrix is evil. It's a rather developed product, just like Mattermost or Flock. But a federated protocol it is not. Please stop advertising as such, and I'll have nothing to say about it.

[1]: https://news.ycombinator.com/item?id=19421978

Re: Telegram Ad Platform

#255
post #145
post #83

Earlier quoted context omitted.

Matrix is an open protocol and anyone's welcome to build a front-end, inspired by Telegram, that your mother would be happy using. Perhaps you meant the Element client?

I'd wager you cannot build a Telegram-tier frontend using Matrix technology. Element is evidence of that. Clearly there's an axis with security on one side and convenience on the other. Tilting fully to either side results in a terrible experience. For me, Telegram strikes the perfect balance. Secure chats have fantastic privacy, while the UX isn't totally garbage. The trade-off is that chats are non-E2EE by default.…

> Signal's has the axis tilted all the way to the "security" end, so that the product is unusable if you aren't a technical expert already.

Sorry, just to confirm: are you saying Signal has worse UX than Element?

Re: Telegram Ad Platform

#256
post #145

Earlier quoted context omitted.

I'd wager you cannot build a Telegram-tier frontend using Matrix technology. Element is evidence of that. Clearly there's an axis with security on one side and convenience on the other. Tilting fully to either side results in a terrible experience. For me, Telegram strikes the perfect balance. Secure chats have fantastic privacy, while the UX isn't totally garbage. The trade-off is that chats are non-E2EE by default.…

> Signal's has the axis tilted all the way to the "security" end, so that the product is unusable if you aren't a technical expert already. How so? What's wrong with Element's UX? It's improved an awful lot lately.

It's slow, very resource intensive on desktop, practically unusable on mobile, you sometimes can't join rooms and the client tells you some weird obscure Matrix error, you sometimes can't leave rooms, the moderations tools are quite poor, etc. etc. etc.
Post reply on HN